Basically, attempting to run mvnd clean install twice in a row failed.
After a lot of debugging, the root cause is the GMavenPlus plugin's class loader. If you create a multi module project where module B depends upon module A and add any execution of the GMavenPlus plugin's execute goal to module B, the subsequent build will fail to clean. This is because (as far as I can tell) GMavenPlus overrides the class loader in the Thread with a custom class loader: https://github.com/groovy/GMavenPlus/blob/master/src/main/java/org/codehaus/gmavenplus/util/ClassWrangler.java#L74
That class loader is holding a lock on the target/ dir's jar of module A since it is a dependency of module B when module B's build executes. This is fine in typical maven since that lock is released when the execution finishes. However, in mavend, that Thread/class loader is cached across builds which causes subsequent cleans to fail. The fix for this to simply specify PLUGIN_ONLY here: https://groovy.github.io/GMavenPlus/execute-mojo.html#includeClasspath
That way module A's jar isn't included on the class path of the plugin by default. Of course, if you need module A in GMavenPlus' execution, I'm not sure how you'd work around this.
We use GMavenPlus extensively in our project and I was attempting to update the project to use mavend. However, I ran into this issue: https://github.com/apache/maven-mvnd/issues/900
Basically, attempting to run
mvnd clean installtwice in a row failed.After a lot of debugging, the root cause is the GMavenPlus plugin's class loader. If you create a multi module project where module B depends upon module A and add any execution of the GMavenPlus plugin's execute goal to module B, the subsequent build will fail to clean. This is because (as far as I can tell) GMavenPlus overrides the class loader in the Thread with a custom class loader: https://github.com/groovy/GMavenPlus/blob/master/src/main/java/org/codehaus/gmavenplus/util/ClassWrangler.java#L74
That class loader is holding a lock on the target/ dir's jar of module A since it is a dependency of module B when module B's build executes. This is fine in typical maven since that lock is released when the execution finishes. However, in mavend, that Thread/class loader is cached across builds which causes subsequent cleans to fail. The fix for this to simply specify PLUGIN_ONLY here: https://groovy.github.io/GMavenPlus/execute-mojo.html#includeClasspath
That way module A's jar isn't included on the class path of the plugin by default. Of course, if you need module A in GMavenPlus' execution, I'm not sure how you'd work around this.
Repo with a reproduction: https://github.com/floverfelt/gmavenplus-mavend-example/tree/main
Run
mvnd clean installtwice in a row on that (using Windows, mvnd 1.0.1) and the issue should appear with error:I'm not sure how that jar is getting on the class path to be locked, it should be coming from the Maven repository, not the local project?
Anyway, I realize this is a highly specific issue and I don't expect a fix, but thought I'd share for anybody else who runs into this.