Reputation: 2255
Im' getting an error when deploying an artifact in my own repository in a Nexus server: "Failed to deploy artifacts: Could not transfer artifact" "Failed to transfer file http:///my_artifact. Return code is: 400"
I have Nexus running with one custom repository my_repo with the next maven local configuration:
settings.xml
<server>
<id>my_repo</id>
<username>user</username>
<password>pass</password>
</server>
...
<mirror>
<id>my_repo</id>
<name>Repo Mirror</name>
<url><my_url_to_my_repo></url>
<mirrorOf>*</mirrorOf>
</mirror>
pom.xml
<distributionManagement>
<repository>
<id>my_repo</id>
<name>my_repo</name>
<url><my_url_to_my_repo></url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots</name>
<url><my_url_to_my_snapshot_repo></url>
</snapshotRepository>
</distributionManagement>
and then I execute
mvn deploy
and get the error. Any idea?
Upvotes: 135
Views: 263997
Reputation: 415
Watch our for your CI doing a deploy after your release:prepare
step. For us it was recent introduction of the official Bitbucket Server Integration plugin in Jenkins that was instantly firing on the push from release:prepare
.
The fix was to add a step in the plugin for "Polling ignores commits with certain messages" with: ^(?s)\[maven-release-plugin\].*
(from https://stackoverflow.com/a/32371336/1399659)
Upvotes: 0
Reputation: 43
I was getting the same 400 response status, and the issue was resolved by adding -Dresume=false
.
mvn -B release:prepare release:perform -Dresume=false
In my case, the release:prepare target was being skipped and the following message was logged in the output.
[INFO] Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag
I suspect that I may have made changes in the pom.xml that required forcing the release:prepare to run again before running release:perform.
Upvotes: 1
Reputation: 1
What worked for me was disabling the ReleaseProfile that comes with the release plugin and skipping the deployment in the deploy plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagNameFormat>v@{project.version}</tagNameFormat
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>releases</releaseProfiles>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Use mvn help:effective-pom
Upvotes: 0
Reputation: 1
Server id should match with the repository id of maven settings.xml
Upvotes: 0
Reputation: 1373
400 Bad Request will be returned if you attempt to:
Upvotes: 40
Reputation: 465
For 400 error, check the repository "Deployment policy" usually its "Disable redeploy". Most of the time your library version is already there that is why you received a message "Could not PUT put 'https://yoururl/some.jar'. Received status code 400 from server: Repository does not allow updating assets: "your repository name"
So, you have a few options to resolve this. 1- allow redeploy 2- delete the version from your repository which you are trying to upload 3- change the version number
Upvotes: 4
Reputation: 941
This can also happen if you have a naming policy around version, prohibiting the version# you are trying to deploy. In my case I was trying to upload a version (to release repo) 2.0.1
but later found out that our nexus configuration doesn't allow anything other than whole number for releases.
I tried later with version 2
and deployed it successfully.
The error message definitely dosen't help:
Return code is: 400, ReasonPhrase: Repository does not allow updating assets: maven-releases-xxx. -> [Help 1]
A better message could have been version 2.0.1 violates naming policy
Upvotes: 2
Reputation: 683
Cause of problem for me was -source.jars was getting uploaded twice (with maven-source-plugin) as mentioned as one of the cause in accepted answer. Redirecting to answer that I referred: Maven release plugin fails : source artifacts getting deployed twice
Upvotes: 17
Reputation: 29912
A couple things I can think of:
Check those and if you still run into trouble provide more details here.
Upvotes: 208
Reputation: 3807
If any of the above answers worked out, You can create new artifact directly from the admin side of (NEXUS Screen shot attached below).
Login to nexus
UI http://YOUR_URL:8081/nexus( username: admin
default password: admin123 )Click repositories
on the left side then click the repo, For eg: click release.artifact Upload
(last tab). GAV definition
as GAV Param
- Then enter your groupid , artifact id and version .Now you will be able to add the corrsponding in your project.(screenshot below)
Upvotes: 1
Reputation: 1298
example :0.0.1-SNAPSHOT
Upvotes: 3
Reputation: 14479
I had the same problem today with the addition "Return code is: 400, ReasonPhrase: Bad Request." which turned out to be the "artifact is already deployed with that version if it is a release" problem from answer above enter link description here
One solution not mentioned yet is to configure Nexus to allow redeployment into a Release repository. Maybe not a best practice, because this is set for a reason, you nevertheless could go to "Access Settings" in your Nexus repositories´ "Configuration"-Tab and set the "Deployment Policy" to "Allow Redeploy".
Upvotes: 4
Reputation: 558
In the rare event that you need to redeploy the SAME STABLE artifact to Nexus, it will fail by default. If you then delete the artifact from Nexus (via the web interface) for the purpose of deploying it again, the deploy will still fail, since just removing the e.g. jar or pom does not clear other files still laying around in the directory. You need to log onto the box and delete the directory in its entirety.
Upvotes: 10
Reputation: 693
Ensure that not exists already (artifact and version) in nexus (as release). In that case return Bad Request.
Upvotes: 3
Reputation: 444
I had this exact problem today and the problem was that the version I was trying to release:perform was already in the Nexus repo.
In my case this was likely due to a network disconnect during an earlier invocation of release:perform. Even though I lost my connection, it appears the release succeeded.
Upvotes: 9
Reputation: 3080
Just to create a separate answer. The answer is actually found in a comment for the accepted answer.
Try changing the version of your artefact to end with -SNAPSHOT
.
Upvotes: 38