Okay, I just found a subtle problem: One of my co-workers has added a slightly older version of the deploy plugin (2.8.1 instead of 2.8.2) to a new pluginManagement section in one of our submodules. Somehow this broke deployAtEnd not just for that submodule but for all modules. When I removed that redundant and conflicting section, deployAtEnd started to work as expected.
Sorry for the noise, but I think this can happen to others too, so it is good there is some record for it on the mailing list. Follow-up question: Can I detect plugin conflicts via Maven Dependency Plugin, similar to dependency:analyze for normal dependencies? -- Alexander Kriegisch > Am 22.01.2016 um 14:11 schrieb Alexander Kriegisch <alexan...@kriegisch.name>: > > Yesterday I rolled another release and again the artifacts were not uploaded. > I cannot share my build log because it contains internal information, but > what I can say is that for each single module I see in the log: > > Deploying <artifact group, name and version> at end > > Then at the end of the successful mvn release:perform build, nothing gets > uploaded despite the advance notice. > > As for your question: I do not use any Tycho/OSGi and no plugins with their > own lifecycle that I would be aware of. > > Do you have any idea what I could have done wrong in order to trigger such a > (non-)deployment behaviour during release:perform? > -- > Alexander Kriegisch > > >> Am 09.01.2016 um 15:06 schrieb Karl Heinz Marbaise <khmarba...@gmx.de>: >> >> Hi Alexander, >> >>> On 1/9/16 2:13 PM, Alexander Kriegisch wrote: >>> Hi community. >>> >>> This inquiry relates to >>> [1] https://issues.apache.org/jira/browse/MRELEASE-664 >>> [2] https://issues.apache.org/jira/browse/MDEPLOY-157 >>> [3] https://issues.apache.org/jira/browse/MINSTALL-93 >>> [4] https://issues.apache.org/jira/browse/MDEPLOY-168 >>> >>> where [2] and [3] are kinda spawned from [1] and [4] has not been >>> implemented yet because it seems to be non-trivial at least, maybe >>> complicated or even complex. >>> >>> Anyway, a combination of [2] and [3] should, as I understand the tickets, >>> permit me to upload (deploy) my build artifacts to a repository manager >>> only at the end of a successful multi-module build. Thus, I added this to >>> my parent POM's pluginManagement section: >>> >>> <plugin> >>> <groupId>org.apache.maven.plugins</groupId> >>> <artifactId>maven-install-plugin</artifactId> >>> <version>2.5.2</version> >>> <configuration> >>> <installAtEnd>true</installAtEnd> >>> </configuration> >>> </plugin> >>> >>> <plugin> >>> <groupId>org.apache.maven.plugins</groupId> >>> <artifactId>maven-deploy-plugin</artifactId> >>> <version>2.8.2</version> >>> <configuration> >>> <deployAtEnd>true</deployAtEnd> >>> </configuration> >>> </plugin> >>> >>> I see artifacts being uploaded to the repository manager per module anyway. >>> Am I doing anything wrong? >> >> If you have defined in pluginManagement be carefull no one overwrites that >> in the child pom or changes the plugin configuration and regrets the >> inherited part by using inherited false ...Furthermore use the correct >> versions... >> >> I'm using this for more than 2 years without any problems.... >> >> BUT are you using plain Maven or some kind of OSGi parts (like tycho) or >> other plugins which define their own lifecycle ? >> >> Can you show an log output of the build ? Or do you have an example project >> which shows that behaviour ? >> >> >> >>> >>> P.S.: Sorry to Karl Heinz for having asked this question in ticket [2], but >>> I thought I had discovered an implementation bug. >> >> No problem... we will see if you have found an other bug or not... >> >> And general rule is to create a separate JIRA ticket and don't reopen closed >> tickets...if it's needed we will link to other tickets... >> >> >> Kind regards >> Karl Heinz Marbaise >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org
smime.p7s
Description: S/MIME cryptographic signature
