22

When I execute mvn release:perform on a parent POM, the server is responding with this error about one of the child projects (filenames redacted):

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on project: Failed to deploy artifacts: Could not transfer artifact from/to repository: Failed to transfer file. Return code is: 400, ReasonPhrase: Bad Request.

However, all the files for this child project are successfully uploaded! I see a new directory (named after the release version number) and it contains all the .jar, .pom, .md5, and .sha1 files one would expect.

I don't have access to the Nexus server, but I'm wondering what might cause this and how to fix it. Is it possible that Maven is trying to upload this particular child project twice? If so, why would Maven be doing this and how can I stop it?

UPDATE: If you're having the same problem, check out the answer with the most upvotes in this post. I ran mvn help:effective-pom and found that the project in question actually had two executions of the deploy phase. Removing one of those executions solved my problem.

Community
  • 1
  • 1
Rob Johansen
  • 5,076
  • 10
  • 40
  • 72
  • Is the version that you are trying to deploy already present ? – StackFlowed Sep 23 '14 at 19:34
  • @wrongAnswer: No. When the error first occurred, I thought maybe that was the problem, so I explicitly deleted the artifact's new directory (along with the directory of another child project that uploaded without errors) and tried again. This resulted in the same problem: Both the child projects uploaded, but the second gave the "Bad Reqeust" again even though it uploaded successfully. – Rob Johansen Sep 23 '14 at 19:43
  • 2
    Can you give the full error ... – StackFlowed Sep 23 '14 at 19:44
  • 1
    Here is the error that I'm getting for a similar setup: https://gist.github.com/arun-gupta/4cb82e44a29561c3d6a4 – Arun Gupta Feb 24 '15 at 11:24
  • You don't have access to Nexus even though you're deploying to localhost:8081? I would try performing a wget on the artifact and see if it truly is there and if it is valid and built with the timestamp you expect (in the manifest file). – gwnp Oct 23 '15 at 14:37

1 Answers1

3

I encountered the same issue, releasing a multi-module project. An error occured the first time but the deploy goal had already contact and then create the appropriate path. Assuming that a "release" repo is a write-once one, the second time I trggered it, refuse to overwrite the path.

So, in such a case, you might ask your admin to delete the repo ... or create a new release.

PS : better late than never ;)

Jean-Rémy Revy
  • 5,607
  • 3
  • 39
  • 65