[ 
http://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202072#action_202072
 ] 

Julien HENRY commented on MDEPLOY-114:
--------------------------------------

We are not using the staging process currently. But you are right, it may 
certainly be a good thing to investigate.

> Add an option to not fail when remote file already exists and redeploy is 
> forbidden
> -----------------------------------------------------------------------------------
>
>                 Key: MDEPLOY-114
>                 URL: http://jira.codehaus.org/browse/MDEPLOY-114
>             Project: Maven 2.x Deploy Plugin
>          Issue Type: Wish
>          Components: deploy:deploy
>    Affects Versions: 2.4
>            Reporter: Julien HENRY
>
> In my organisation we are using a MRM (Nexus) with redeployment of release 
> that is forbidden.
> Sometimes the release:perform may fail in the middle of a multi-module 
> release. It means some modules were deployed but other are not.
> Currently it is not possible to restart the release as it will fail on first 
> deployment (usually the parent pom of the multimodule) because the pom was 
> already deployed during the first attempt.
> I would like to add an option to the deploy plugin that may deal with this 
> case. Perhaps an option like -Dredeploy=false that may either :
> 1) check if the remote file already exists before trying to upload
> 2) try to upload everytime but not fail the build
> The problem with the second proposal is the error returned by Nexus is 
> authorization error so we may not be able to distinguish real authorization 
> error on a new file and redeploy attempt.
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException: 
> Access denied to: http://nexus.mycompany.com/
> content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom
>         at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360)
> Other options may be more complicated like implementing an atomic deploy 
> process on multimodule (may need a big change of the deploy protocol).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to