[ 
https://jira.codehaus.org/browse/MDEPLOY-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333145#comment-333145
 ] 

Dominik Bartholdi commented on MDEPLOY-156:
-------------------------------------------

you'r right, MDEPLOY-118 would be good solution
                
> 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

Reply via email to