Error when deploying an artifact in Nexus

Question

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>

• user has permissions to create/read/write into my_repo -

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?

Poundfoolish

HTTP 400 means "bad request". I'm guessing one of URLs is incorrect. – Samaritan

for me the problem was that it was not a snapshot version. – Jen

Answer 1

A couple things I can think of:

• user credentials are wrong
• url to server is wrong
• user does not have access to the deployment repository
• user does not have access to the specific repository target
• artifact is already deployed with that version if it is a release (not -SNAPSHOT version)
• the repository is not suitable for deployment of the respective artifact (e.g. release repo for snapshot version, proxy repo or group instead of a hosted repository)

Check those and if you still run into trouble provide more details here.

Tortilla

I changed version of my artifact to SNAPSHOT and then deploy and all was ok. Then I realized that I was trying to deploy to a Nexus group (not a Nexus repository), so the cause of my problem was: 'url to my nexus repository was wrong' – Poundfoolish

where did you found this more specific error 'url to my nexus repository was wrong' having similar issue and not seeing it in logs – Zink

Ask a new question.. but basically you have to use the url of a hosted repository – Tortilla

IMPORTANT : "artifact is already deployed with that version if it is a release (not -SNAPSHOT version)" – Wreckfish

Saved my day... I removed the -SNAPSHOT word from version in pom.xml, that is why its not able to deploy on to nexus... I added the SNAPSHOT word back , and it worked .. – Dockhand

In my experience wrong credentials result in 401, not 400. Suffixing the version name with "-SNAPSHOT" fixed the issue for me. – Nichols

I my case the issue, version name was not unique for every build in continuous delivery setup and nexus was rejecting the duplicate artifact. – Aweigh

error 401 is an authentication issue and error 400 means you are reaching the nexus server and executing the goal has failed like uploading the artifact has failed. so, status code 400 means, it could be that re-deply is disabled. – Ifill

I had some old .m2/settings.xml which missed the configuration and esp. credentials for our snapshot repository, adding that fixed my issues with deploying. – Overblouse

you can simply change the deployment policy of your repository to enable redeploy – Scevor

@furqan while that is possible, it is also a terrible idea since it violates the idea that releases are immutable. – Tortilla

@ManfredMoser yes, I realized this and I tried to answer below. – Scevor

artifact is already deployed with that version if it is a release (not -SNAPSHOT version) This was the reason for me. – Jen

this one helped me. The problem was that I had to do a revert, which caused the project version number to be reverted as well, causing problems because the version which was reverted to was already on nexus. I then manually upped the version number and the job finished in success – Calibrate

In my case my repo was accidentally using an npm repo and I was trying to use maven to deploy. I had to change to the nexus maven repo. – Surgy

hahah ... too many different repo formats around these days right @Jared – Tortilla

Can anyone help here #75045834 – Bolin

Using an http url that redirects to https is another possible cause. To fix, use the https url right way. – Gasbag

Answer 2

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.

Blanket

No you are missing the whole point, read the comment carefully it mentions "so the cause of my problem was: 'url to my nexus repository was wrong' ". And get some idea about what is meant be 'Return code is: 400' (before you just copy someones comments as answer) – Starlight

Just wanted to comment here since I hit this page in my searching. I ran into the same 400 error and what bhagyas said here is key (though I didn't realize it at the time), if deploying to a snapshot repository the version MUST end in -SNAPSHOT. My version was 1.13.0.SNAPSHOT and it took me an hour to figure out it needed to be 1.13.0-SNAPSHOT. – Acrylonitrile

Answer 3

400 Bad Request will be returned if you attempt to:

1. Deploy a snapshot artifact (or version) ending in -SNAPSHOT to a release repository
2. Deploy a release artifact (version not ending in -SNAPSHOT) to a snapshot repository
3. Deploy the same version of a release artifact more than once to a release repository

Suannesuarez

My error is in case 3: I must to enabled Deployment policy: allow-redeploy in Nexus for sure it successfully. – Bleed

Answer 4

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

Taro

Answer 5

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.

Emmanuelemmeline

Just to add to this, if you dont have interactive access to the server (I dont - its a managed box), you can delete the offending artifact with a HTTP DELETE. I use PostMan for this purpose – Tuyettv

I'm not sure if it's because I'm using the S3 blobstore plugin, but I don't see a directory structure that matches the repo structure. Is there some trick to identifying which dirs to delete? All my files are named with a hash. The directories are of the format content/vol-{01-43}/chap-{01-47} – Despairing

You can also delete all of the files for a release by navigating to the release directory from the repository, instead of looking for the artifact from a GAV type search. In the repository view, you can right-click on the directory to get a delete action for all files at that GAV. – Alexi

Answer 6

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.

Tetrabasic

Answer 7

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

Inveigle

Answer 8

• in the parent pom application==> Version put the tag as follows: x.x.x-SNAPSHOT

example :0.0.1-SNAPSHOT

• "-SNAPSHOT" : is very important

Capote

Answer 9

Ensure that not exists already (artifact and version) in nexus (as release). In that case return Bad Request.

Schnapp

Answer 10

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

Scevor

Allowing redeployment for releases repository is usually not considered a good practice. Do not do that without consideration. – Pegpega

@Pegpega you are right that is why I have suggested a few other suggestions. In my opinion, changing the version is better. – Scevor

Answer 11

If any of the above answers worked out, You can create new artifact directly from the admin side of (NEXUS Screen shot attached below).

1. Login to nexus UI http://YOUR_URL:8081/nexus( username: admin default password: admin123 )
2. Click repositories on the left side then click the repo, For eg: click release.
3. Choose artifact Upload (last tab).
4. Choose GAV definition as GAV Param- Then enter your groupid , artifact id and version .
5. Choose Jar file.
6. Click upload artifact. Thats it !

Now you will be able to add the corrsponding in your project.(screenshot below)

Gametogenesis

Answer 12

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

Fiscus

Answer 13

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.

Helenahelene

Answer 14

Server id should match with the repository id of maven settings.xml

Organize

Answer 15

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

Glycerinate

Answer 16

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://mcmap.net/q/174928/-stop-mvn-release-triggering-repeat-jenkins-builds)

Implore