I have a situation where I am upgrading applications to Spring Boot 3 which has a few external libraries. Regarding the javax namespace change in the JEE9 Spec, rather than wait for these projects to create spring boot 3 compatible releases or forking the project, Ive create a plugin which at compile time changes the bytecode and updates the jakarta namespace for me that way.
For that I leverage the maven-dependency plugin, copy-deps goal and can build the Jar with the migrated jakarta jar. However when I bootify the jar with repackage using the spring boot maven plugin, it copies the non migrated jar to the libs dir, it doesn't use the directory specified in maven-dependency plugin at all.
From the documentation I cant see a way to configure the plugin to handle this scenario. Would you consider adding this capability to the plugin?
Comment From: wilkinsona
@Megagyger can you please share a sample project that demonstrates your approach? I'd like to see how you've set things up so that compilation, test execution, etc make use of the rewritten bytecode so that we can see why repackaging does not.
Comment From: Megagyger
@wilkinsona I pushed an example project here https://github.com/Megagyger/maven-jakarta-migration-plugin
It seems my belief that maven would use deps from the custom-repo from the copy-dependencies phase in subsequent lifecycle phases was wrong. As you will see from the tests, the original Jar is the one on the classpath and loaded from the local mvn repository. So I have to conclude that even the projects original jar when compiled will be compiled with the non migrated jar.
Still however I think something like this could be useful to the community if it did what is intended as I know the netflix gradle one was particularly useful for them and not just with deps, also with the autoconfiguration change from spring.factories.
Comment From: wilkinsona
Thanks. What you have described matches my expectation of how things would behave.
I agree that this could be useful, but I don't think Spring Boot is the right place to provide the functionality. Maven's architecture prevents a plugin from having this level of control so I think it needs to be addressed in Maven itself. That would allow plugins like Surefire and Failsafe to execute tests using the rewritten classes as well as allowing Spring Boot's Maven plugin or Maven's war plugin to package the rewritten dependencies in the archives that they produce.
Comment From: Megagyger
Yep, that is what I feared. So a plus point, finally at least I see one example outside of Big Frameworks with long builds where gradle triumphs over maven.