Maven 2.x and 3.x Deploy Plugin

Add an option to not fail when remote file already exists and redeploy is forbidden

Details

  • Number of attachments :
    0

Description

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).

Issue Links

This issue relates to:
MDEPLOY-118 Enable deployment of attached release artifacts if POM is identical Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

Why not simply drop the staging repository in Nexus before redoing the release?

Show
Benjamin Bentmann added a comment - Why not simply drop the staging repository in Nexus before redoing the release?
Hide
Permalink
Julien HENRY added a comment -

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

Show
Julien HENRY added a comment - We are not using the staging process currently. But you are right, it may certainly be a good thing to investigate.
Hide
Permalink
Jaan Vajakas added a comment -

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).

Show
Jaan Vajakas added a comment - 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).

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.