[MNG-6209] inconsistent activation of components from multiple extensions=true plugins

[jira-importer]

Igor Fedorenko opened MNG-6209 and commented

This is a regression introduced by the fix for MNG-5742. When multiple extensions=true plugins configured in the build, when mojos from one such plugin are executed, components from other extensions are ignored.

---

Affects: 3.3.1, 3.3.3, 3.3.9

Issue Links:

• MNG-5742 inconsistent classloading for extensions=true plugins

• MASSEMBLY-858 don't read assembly descriptor from thread classloader but plugin classloader
  ("breaks")

0 votes, 6 watchers

[jira-importer]

Igor Fedorenko commented

The proposed fix: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=53a2af8ee11fc3f4aa829193b99cde95a3f04735
The corresponding IT: https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=f476ac3d4567312dcd9ea0975ce5cba84ddcb1ec

[jira-importer]

Igor Fedorenko commented

fixed in master

[jira-importer]

Michael Osipov commented

This fix now breaks a lot of MASSEMBLY ITs related to classpath resources:

[INFO] --- maven-invoker-plugin:3.0.0:verify (integration-test) @ maven-assembly-plugin ---
[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO]   Passed: 119, Failed: 14, Errors: 0, Skipped: 2
[INFO] -------------------------------------------------
[ERROR] The following builds failed:
[ERROR] *  projects\bugs\massembly-306\pom.xml
[ERROR] *  projects\descriptor-refs\bin\jars-in-archive-root\pom.xml
[ERROR] *  projects\descriptor-refs\jar-with-dependencies\component-descriptors-merged\pom.xml
[ERROR] *  projects\descriptor-refs\jar-with-dependencies\deps-unpacked-to-root-dir\pom.xml
[ERROR] *  projects\descriptor-refs\jar-with-dependencies\no-target-dir\pom.xml
[ERROR] *  projects\descriptor-refs\project\multimodule-sources-copied\pom.xml
[ERROR] *  projects\descriptor-refs\project\no-target-dir-multimodule\pom.xml
[ERROR] *  projects\descriptor-refs\project\no-target-dir\pom.xml
[ERROR] *  projects\descriptor-refs\project\sources-copied\pom.xml
[ERROR] *  projects\descriptor-refs\src\no-target-dir\pom.xml
[ERROR] *  projects\descriptor-refs\src\src-dir-copied\pom.xml
[ERROR] *  projects\mojo-configuration\manifest-with-customEntry\pom.xml
[ERROR] *  projects\mojo-configuration\manifest-with-mainClass\pom.xml
[ERROR] *  projects\mojo-configuration\no-appendAssemblyId-no-classifier\pom.xml
[INFO] -------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12:05 min
[INFO] Finished at: 2017-06-05T13:14:21+02:00
[INFO] Final Memory: 88M/1005M
[INFO] ------------------------------------------------------------------------

Please have a look how this can be fixed or revert the commit for now.

[jira-importer]

Igor Fedorenko commented

I am not familiar with maven assembly plugin implementation, sorry. Do you think you can provide Maven IT that shows the problem?

[jira-importer]

Michael Osipov commented

You can simply take this IT and invoke as Maven Core IT. The key is about the descriptorRef this is located in the same JAR and the plugin. It could be also on the plugin classpath. This classpath is now gone and the descriptor (assembly.xml) cannot be loaded:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:3.0.1-SNAPSHOT:single (assembly) on project manifest-with-mainClass: Error reading assemblies: Descriptor with ID 'jar-with-dependencies' not found -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:3.0.1-SNAPSHOT:single (assembly) on project manifest-with-mainClass: Error reading assemblies: Descriptor with ID 'jar-with-dependencies' not found
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:937)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading assemblies: Descriptor with ID 'jar-with-dependencies' not found
	at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:447)
	at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:61)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 20 more
Caused by: org.apache.maven.plugins.assembly.io.AssemblyReadException: Descriptor with ID 'jar-with-dependencies' not found
	at org.apache.maven.plugins.assembly.io.DefaultAssemblyReader.addAssemblyForDescriptorReference(DefaultAssemblyReader.java:210)
	at org.apache.maven.plugins.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:125)
	at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:443)
	... 23 more
[ERROR]

Is that enough for an IT for you?

[jira-importer]

Igor Fedorenko commented

Why does assembly plugin use Thread.currentThread().getContextClassLoader() to retrieve assembly.xml descriptor? If the descriptor is located in the same jar as the plugin (or at least in the same classloader), getClass().getClassLoader() seems like the proper way to get the descriptor, no?

[jira-importer]

Michael Osipov commented

I am not certain. The code remained the same for more than seven years now. The descriptor can also be located in another JARs, but always on the plugin classpath.

I did apply now this patch locally:

Index: src/main/java/org/apache/maven/plugins/assembly/io/DefaultAssemblyReader.java
===================================================================
--- src/main/java/org/apache/maven/plugins/assembly/io/DefaultAssemblyReader.java       (revision 1797662)
+++ src/main/java/org/apache/maven/plugins/assembly/io/DefaultAssemblyReader.java       (working copy)
@@ -196,7 +196,7 @@
                                                             InvalidAssemblerConfigurationException
     {
         final InputStream resourceAsStream =
-            Thread.currentThread().getContextClassLoader().getResourceAsStream( "assemblies/" + ref + ".xml" );
+            getClass().getClassLoader().getResourceAsStream( "assemblies/" + ref + ".xml" );

         if ( resourceAsStream == null )
         {

and it does work. So Igor, you idea was correct. Hervé Boutemy, Igor Fedorenko, what bothers me now is that decriptor ref usecases with 3.5.1 will be broken when shipped even if I address this issue in MASSEMBLY. Any thoughts?

[jira-importer]

Hervé Boutemy commented

since when is this thread classloader used by maven-assembly-plugin? It's a surprising choice.

IMHO, the minimum will be to have a maven-assembly-plugin release before we ship Maven 3.5.1, and add this to release notes: this assembly plugin was fragile relying on thread context classloader without apparent real need, we'll just help users know the issue and fix when upgrading Maven to 3.5.1

[jira-importer]

Igor Fedorenko commented

Agree with Hervé. Thread context classloader use is a bug in maven assembly plugin and needs to be fixed there.

[jira-importer]

Hervé Boutemy commented

I looked into m-assembly-p history and found the commit in question: for MASSEMBLY-331
the change does not look related to real bug fixing, just a change that was apparently innocent...

[jira-importer]

Hervé Boutemy commented

I created and fixed MASSEMBLY-858: whatever we do, this plugin should not use thread classloader

then I was worried about one question: with MNG-6209 fixed in Maven 3.5.1, does that mean that any component already released with a version of m-assembly-p <= 3.0.0 will fail when loading a descriptor from a jar file? This would make Maven 3.5.1 quite unusable to rebuild anything already released (then with a failing m-assembly-p)

then I just found that m-assembly-p was declaring <extension>true</extension> in its parent pom: this is what cause the MNG-6209 fix to break the plugin. But in real life, who declares m-assembly-p as extension plugin? Why are these its doing so?
If my analysis is confirmed, that would make Maven 3.5.1 usable with old m-assembly-p versions: that would be a good news.
WDYT?

[jira-importer]

Hervé Boutemy commented

I just tested: I removed the extension in m-assembly-p ITs and removed the plugin fix
as expected, since the plugin is not extension, MNG-6209 does not make the ITs fail

then good news: this fiw won't break normal builds from the past, but only builds that declare the m-assembly-p as extension = something that should not happen

I think now we can close this issue as fixed without fear for compatibility with the past

[jira-importer]

Michael Osipov commented

Hervé, I do agree. Issue has been fixed in source. Did you check blame why the extension flag was added to the IT?

[jira-importer]

Hervé Boutemy commented

yes: it was there a long time ago, near from the first import: not really tied to any change. I suppose it was in the early Maven days, when a lot of parts were moving and the classpath structure with realms was not so clear: flagging the plugin as extension was an easy insurance against any change, and did not seem to cause any serious issue
this extensions plugins thread classpath change is a good opportunity of cleanup :)
and we're lucky it finally does not hit normal users, but just cleans up plugin and ITs

[jira-importer]

Vinay Shankar commented

Igor Fedorenko - Could you please create a PR for the commits if they have not been merged yet? According to the link https://issues.apache.org/jira/projects/MNG/versions/12338964, the 3.5.1 release is pending due to unreviewed commits from MNG-6209.

3.5.0 has a bug (MNG-6240 and MDEPLOY-221) and a 3.5.1 release will be very useful.