[ 
https://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MDEPLOY-114.
----------------------------------

    Resolution: Won't Fix
      Assignee: Robert Scholte

I can think of 2 reasons why a {{release:perform}} fails:
- A failure occurs during the build, for instance because tests fail. In such 
cases you would like to deploy all artifacts at the end, a feature added with 
MDEPLOY-157
- The deployment itself fails due to connection issues. In this case you could 
use the {{--resume-from <module>}} option.

I'd prefer to solve the root-cause, so closing this as "won't fix".
(don't mind reopening this issue if you have a usecase which requires this 
feature)
                
> Add an option to not fail when remote file already exists and redeploy is 
> forbidden
> -----------------------------------------------------------------------------------
>
>                 Key: MDEPLOY-114
>                 URL: https://jira.codehaus.org/browse/MDEPLOY-114
>             Project: Maven 2.x and 3.x Deploy Plugin
>          Issue Type: Wish
>          Components: deploy:deploy
>    Affects Versions: 2.4
>            Reporter: Julien HENRY
>            Assignee: Robert Scholte
>              Labels: contributers-welcome
>
> 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, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to