[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365853#comment-365853
]
Emmanuel Lécharny edited comment on MRELEASE-880 at 3/29/15 5:29 PM:
---------------------------------------------------------------------
To be clear : it's *not* a bug in the Maven Release plugin. It's just that
Nexus is not able to keep going during a long release.
The thing is that even if nexus has pb, there should be a way to mitigate that
by allowing the RM to restart from the point where the release was stopped,
instead of starting it all over again (which, in may case, can take more than
one hour - if the release does not fail, of course -)
There is no problematic module per se : the breakage is purely random (and
sadly, systematic). Again, Nexus is the one to blame here, but alas, I have
reported the pb to them many times, they still don't have a solution... So you
seems to say that using deploy by hand after the release has been completed
would help here ? (FTR, we don't use any extension, and my current workaround
is to run a {{mvn deploy}} after the release, which allows me to resume where
it failed. That could do the trick.)
was (Author: elecharny):
Ti be clear : it's *not* a bug in the Maven Release plugin. It's just that
Nexus is not able to keep going during a long release.
The thing is that even if nexus has pb, there should be a way to mitigate that
by allowing the RM to restart from the point where the release was stopped,
instead of starting it all over again (which, in may case, can take more than
one hour - if the release does not fail, of course -)
There is no problematic module per se : the breakage is purely random (and
sadly, systematic). Again, Nexus is the one to blame here, but alas, I have
reported the pb to them many times, they still don't have solutions... So you
seems to say that using deploy by hand after the release has been completed
would help here ? (FTR, we don't use any extension, and my current workaround
is to run a {{mvn deploy}} after the release, which allows me to resume where
it failed. That could do the trick.)
> Cannot restart from a failure
> -----------------------------
>
> Key: MRELEASE-880
> URL: https://jira.codehaus.org/browse/MRELEASE-880
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
> Affects Versions: 2.5
> Reporter: Emmanuel Lécharny
> Priority: Blocker
>
> It's currently quite impossible to cut a release on a big Apache project if
> the remote server has hickups.
> I tried to release Apache Directory Server this morning, and for some unknown
> reasons, I get various and random failures like :
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy
> (default-deploy) on project apacheds-core-api: Failed to deploy
> artifacts: Could not transfer artifact
> org.apache.directory.server:apacheds-core-api:jar:tests:2.0.0-M17
> from/to apache.releases.https
> (https://repository.apache.org/service/local/staging/deploy/maven2):
> Failed to transfer file:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/directory/server/apacheds-core-api/2.0.0-M17/apacheds-core-api-2.0.0-M17-tests.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> (note that if I restart the {{release:perform}}, the error I will get will be
> different).
> There is no way I can restart the perform from another point (like the
> failing module) but the very beginning.
> At the very end, I did a {{mvn deploy -Papache-release}} from
> {{target/checkout}} as a workaround...
> The real pb is that the release plugin should not simply bail when it gets
> some error attempting to reach a remote server. Asking the user about doing a
> retry should be the way to go.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
