[MDEPLOY-193] deployAtEnd does not deploy artifacts for multi-module project with build extensions

[jira-importer]

Jörg Sesterhenn opened MDEPLOY-193 and commented

The deploy plugin shows the same behaviour as described in MINSTALL-102.

We noticed that multimodule projects do not deploy any artifacts if there are modules with packagings that add build extensions (e.g. atlassian-plugin, aar = axis archives).

This issue is here for better visibility as discussed in MINSTALL-102.
Please find attached testcase there.

---

Affects: 2.8.2

Attachments:

• deployAtEndFailure.zip (10.56 kB)

Issue Links:

• MDEPLOY-226 DeployAtEnd fails when module has extension

• MDEPLOY-157 Add deployAtEnd option for multimodule projects

• MDEPLOY-201 deployAtEnd issue for multi-module projects

• MDEPLOY-176 With DeployAtEnd activated and a project using customized lifecycle plugin, deploy is skipped

Remote Links:

• GitHub Pull Request #20
  

20 votes, 29 watchers

[jira-importer]

bob commented

Attached a project, which generate the issue,
run mvn deploy -Pjar,war,osgi

The build is SUCCESSFULL but nothing has been deployed (the worst case).

[jira-importer]

Robert Scholte commented

deployAtEnd is an experimental feature (I added that comment too late). It works for most projects, but not all. Hence it is not active by default. Once MNG-5666 is implemented no-one needs this option anymore.
I'm pretty sure this can't be resolved within the maven-deploy-plugin itself, it's already stretched to its limits.

[jira-importer]

Jérôme Joslet commented

I issue this problem today and found a workaround.

The maven-deploy-plugin records its state in static variables. One for stacking deploy requests (deployRequests) and another one for counting ready project (readyProjectsCounter). When the problem occurs, there is more than one static variable used to count ready projects. This happens when there is more than one classloader that loads the deploy plugin's classes. This leads to multiple class instances and multiple static variable instances. Some module count on one instance and others modules on another one.

The result is that the deploy plugin never flush its pending deploy requests since no counter is equal to the number of project in the reactor.

As mentionned in the following documentation : https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html :
??For projects that use build extensions, plugin classloaders are wired to project classloaders. This gives plugin code access to both Maven API packages and packages exported by the project build extensions. Maven will create one and only one classloader for each unique plugin+dependencies+build-extensions combination.??

and

??Maven guarantees there will be one and only one project classloader for each unique set of project build extensions and the same classloader will be used by all projects that have the set of build extensions.??

The workaround is to declare all extension plugins, with all their extra <dependencies>, in the parent project. This assures that the same classloader is used for loading plugin in all modules.

[jira-importer]

Jakub Bochenski commented

Jérôme Joslet great job, I wish you could upvote comments on JIRA (sorry for spam)

[jira-importer]

Robert Seidel commented

Chas Honton has a solution for this by using session user properties and he already created a pull request https://github.com/apache/maven-deploy-plugin/pull/1. 

Another guy analyzed the problem (http://dev.eclipse.org/mhonarc/lists/aether-users/msg00387.html):

Also, your analysis suggests a bug in the maven-deploy-plugin in that it relies on the erroneous assumption that a single class loader is used per plugin through out a multi-module build.

 All the issues 193, 200, 224, 225, 226 are related to each other.