After introducing Maven Invoker to launch the OpenRewrite Maven plugin and listen for Maven lifecycle events to access the MavenSession the LST parity tests started failing.
Debugging showed that this appears to be caused by an error in MavenEmbedder which does not provide the correct classpath.
The custom RewriteProjectParser "fixes" this by creating the classpath differently. This is a prerequisite to allow "partial parsing" of a sub-tree of the build module hierarchy.
This leads to a situation where the OpenRewrite code does not produce a valid LST and thus the LST is incorrect and differs from the LST produced by RewriteProjectParser.
Possible Solutions
One solution to this problem would be to raise the level of abstraction and not compare LSTs but the produced output of recipes applied with each parser (RewriteProjectParser and OpenRewrite's MavenMojoProjectParser) to verify parity.
The existing test should not be removed because they'd be valuable when the problem is solved.
After introducing Maven Invoker to launch the OpenRewrite Maven plugin and listen for Maven lifecycle events to access the
MavenSessionthe LST parity tests started failing. Debugging showed that this appears to be caused by an error in MavenEmbedder which does not provide the correct classpath. The customRewriteProjectParser"fixes" this by creating the classpath differently. This is a prerequisite to allow "partial parsing" of a sub-tree of the build module hierarchy. This leads to a situation where the OpenRewrite code does not produce a valid LST and thus the LST is incorrect and differs from the LST produced byRewriteProjectParser.Possible Solutions
One solution to this problem would be to raise the level of abstraction and not compare LSTs but the produced output of recipes applied with each parser (
RewriteProjectParserand OpenRewrite'sMavenMojoProjectParser) to verify parity.The existing test should not be removed because they'd be valuable when the problem is solved.