[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365920#comment-365920
]
Robert Scholte commented on MRELEASE-880:
-
http://markmail.org/message/7yf5aesg5fkackoo mentions the same issue...
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365850#comment-365850
]
Robert Scholte commented on MRELEASE-880:
-
Maven itself has 1.7M LOCs, though much less modules. But that shouldn't
matter. You might want to find out why Nexus gave the 400? Not sure if it could
be a checksum failure.
We've introduced
[deploy#deployAtEnd|http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd],
which should work for common projects (let's say 80-90%), but if your project
uses extensions or other advanced Maven features, this might not work due to
current architecture of Maven. Just give it a try on the SNAPSHOTs first.
You should try to run {{mvn deploy -Papache-release}} on the SNAPSHOT sources
and see if you can reproduce it. If so, try to determine the problematic
module. If not, then it might be related to memory or so due to the overhead of
the maven-release-plugin while reinvoking Maven.
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365848#comment-365848
]
Emmanuel Lécharny commented on MRELEASE-880:
In this context, the error 400 does certainly not mean that there is already an
existing release, because I'm just cutting a release ! And doing a whole
release again does not work either, best case, it fails again, somewhere else.
The pb is that my release is not about a few modules and a few thousands lines
of code : Apache Directory release is about 50 modules and around 500 K lines
of code.
Sounds like there is no workaround for the moment ?
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-880:
Component/s: perform
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-880:
Description:
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.
was:
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 :
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.
(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.
Cannot restart from a failure
-
Key: MRELEASE-880
URL: https://jira.codehaus.org/browse/MRELEASE-880
Project: Maven Release Plugin
Issue Type: Bug
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365840#comment-365840
]
Robert Scholte commented on MRELEASE-880:
-
The {{400, ReasonPhrase: Bad Request}} often means you're try to release a
version which has already been released. So in such case a restart won't help:
you'll need to do the whole release all over again with a better version number.
However, you're exposing a problem in Maven Core. What you want to do is add
the {{\-\-resume-from}} argument, but the reactor need to be complete, so you
also need to add {{\-\-also-make}}. AFAIK {{deploy}} will also be used for the
latter group of modules, which will definitely cause a {{Bad Request}}.
Anyhow, first of all the maven-deploy-plugin must be able to deploy only the
{{\-\-resume-from}} modules, before we can fix it here.
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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] (MRELEASE-880) Cannot restart from a failure
[
https://jira.codehaus.org/browse/MRELEASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365853#comment-365853
]
Emmanuel Lécharny commented on MRELEASE-880:
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)
[jira] (MRELEASE-880) Cannot restart from a failure
Emmanuel Lécharny created MRELEASE-880: -- Summary: Cannot restart from a failure Key: MRELEASE-880 URL: https://jira.codehaus.org/browse/MRELEASE-880 Project: Maven Release Plugin Issue Type: Bug 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 : 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. (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)
