[
https://jira.codehaus.org/browse/MDEPLOY-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-156.
----------------------------------
Resolution: Duplicate
Assignee: Robert Scholte
I prefer the solution of MDEPLOY-118.
With your suggested solution, a single flag, you have no control over which
deploy errors should actually be ignored and which not.
Also you should avoid profiles as much as possible. Most of the time these are
used for the wrong reason, which makes deployments more complicated than
necessary.
> Add flag to 'ignoreReleaseDeployErrors' to ease multi module release builds
> with classifiers.
> ---------------------------------------------------------------------------------------------
>
> Key: MDEPLOY-156
> URL: https://jira.codehaus.org/browse/MDEPLOY-156
> Project: Maven Deploy Plugin
> Issue Type: New Feature
> Reporter: Dominik Bartholdi
> Assignee: Robert Scholte
> Attachments: ignoreDeployErrors.patch
>
>
> Add a parameter to allow ignoring deployment errors for release artifacts,
> this is helpful if you'r releasing a multimodule project from a tag, where
> some modules are deployed with different classifiers and you let it to the
> repository manager to decide which ones can be deployed or not (a good repo
> manager blocks deployments of the same artifact with the same release
> version, but different classifiers are allowed). By using this flag one does
> not have to fiddle with the 'skip' flag, but lets the remote repository to
> make the decision. Therefore the idea is to have a kind of an automated
> 'skip' mode.
> In our usecase we have a project with more then 40 modules and multiple
> profiles for about 10 of the modules. Each profile will create the
> corresponding artifact (not every) with a new classifier. Therefore, until
> all modules are deployed, the build has to be triggered about 10 times. IN
> this scenario, the build manager should not have to care about which of the
> modules have to be build in a separate build, but should be able to trigger
> the whole build with from the top level and maven/infrastructure should take
> care about which artifacts is allowed/must be deployed to the repository
> manager.
> Note: as SNAPSHOTs can be overwritten in any case, there is no sense in
> having the same for SNAPSHOTs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
