[
https://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283061#comment-283061
]
Jaan Vajakas commented on MDEPLOY-114:
--------------------------------------
Same problem here: if the deployment of a multi-module project fails in the
middle (e. g. because of lost Internet connection) then I cannot resume the
deployment. The Nexus web interface allows deleting artifacts one-by-one but
this is very tedious in case of many submodules.
An option like -Dredeploy=false with either behavior 1) or 2) would be very
helpful indeed (or maybe just Nexus would need a better GUI for deleting
multiple artifacts).
I think such solutions would be simpler to use than the staging process if one
does not need the staging process for other purposes (especially since one
could use the usual deployment process and only in the case of failure would
one need to take extra steps).
> 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
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
