Rewrite Maven Plugin does not respect recipe libraries’ <dependencyManagement>, here is why

[DidierLoiseau]

I wanted to do some followup on the issue I mentioned in this comment on rewrite-migrate-java#563, as I did some investigations.

The premise is this: I’m setting up my own recipe library, which uses recipes from rewrite-spring. I also want to use a different version of rewrite-migrate-java than the one on which it depends, so I’m specifying it in <dependencyManagement>. I check with mvn dependency:tree and it shows the right version of the dependencies, so all seems good.

I then run the rewrite-maven-plugin and… nope, it’s using the other version of rewrite-migrate-java!

I have setup a small repository that shows this. Install the library in your local repository with mvn clean install, then run it on any Maven project with

mvn org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.activeRecipes=com.example.CheckRewriteMigrateJavaVersion -Drewrite.recipeArtifactCoordinates=com.example:rewrite-recipe-library:1.0-SNAPSHOT

It will print the version of rewrite-migrate-java being used, and the recipe validation will fail if it’s the wrong one (btw, shouldn’t this make the build fail?)

My investigations show that the issue does not come from the Rewrite plugin itself, but from Maven & Maven Resolver, on which it relies. Indeed, it appears that Maven 3 uses a Maven Resolver DependencyManager which ignores the <dependencyManagement> of (transitive) dependencies, for dependencies on which they don’t depend explicitly. See MNG-5761 (and related issues) for more details.

In Maven 4 (currently in beta), they have tried to change this in MNG-7982, but it does not fix it for first level dependencies – as we have here (the recipe is first level below the plugin). I hope this will change before the final release because that seems quite inconsistent.

As a workaround it’s possible to either add a direct dependency on the desired library, or add that library to the recipeArtificatCoordinates like this: (as suggested by @timtebeek)

org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.activeRecipes=com.example.CheckRewriteMigrateJavaVersion -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:2.26.1,com.example:rewrite-recipe-library:1.0-SNAPSHOT

I don’t know if the Rewrite plugin should do anything about it (it might be possible to change the DependencyManager being used), but I thought it would be interesting to know for anyone affected.

[DidierLoiseau]

For anyone interested, I ended up reporting MNG-8295 for Maven 4, and then worked together with their devs so we got it fixed wih apache/maven#1788 🙂

It should thus work as intended with Maven 4! 🎉 (whenever it gets released 😏)

[timtebeek]

Awesome work! One more reason to look forward to mvn4!

[DidierLoiseau]

Just curious @timtebeek, do you already have plans to support Maven modelVersion 4.1.0? Outside the change of dependency management above, all fields in <parent> should become optional when they can be retrieved via the <relativePath> (which is itself optional) and the <version> of dependencies will also be optional when the dependency is part of the same reactor.

<modules> becomes <subprojects> (to avoid confusion with Java modules), which can also be omitted entirely.

Of course, there is no official calendar for the Maven 4 release (I think we can expect a beta 5 soon), so it’s difficult to determine the urgency, a lot of things can still change, and projects will not switch immediately anyway.

[timtebeek]

I'd been somewhat aware of those changes, but hadn't started any work to enable that from our side just yet, in part as the timeline isn't set yet.

Could be interesting to explore the first betas and support the migration, but I don't expect demand to pick up until a release is near.