Menu
I'm using maven-deploy-plugin in multi-module project with deployAtEnd property set to true.
After executing mvn deploy in root project, deploy plugin is executed for each subproject - I can see something like:
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ subproject-name ---
[INFO] Deploying package:subproject-name:v1.1 at end
Last invocation is for root project:
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ parent-project ---
[INFO] Deploying package:parent-project:v1.1 at end
and that's all, actual deployment is not executed.
How do I make deploy plugin work correctly in multi-module project with deployAtEnd=true?
433
clean : removes files generated at build-time in a project's directory ( target by default) install : installs the package into the local repository, for use as a dependency in other projects locally.
The deploy plugin is primarily used during the deploy phase, to add your artifact(s) to a remote repository for sharing with other developers and projects. This is usually done in an integration or release environment.
release:perform will fork a new Maven instance to build the checked-out project. This new Maven instance will use the same system configuration and Maven profiles used by the one running the release:perform goal.
As we just ran into this issue today, I found the related issue in maven-deploy-plugin:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MDEPLOY-193
Jérôme Joslet explantation in this issue :
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.
98
Today I resolved the same problem in my project.
The problem modules have extansions (<extension> tags). They violate a counter of built modules in maven-deploy-plugin.
To fix it I moved <extension> to the root POM.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
