Important: The file parameters MUST COME LAST or the curl commands will not work. If you are uploading a pom file, then the pom file parameter must come before the rest of the file parameters, but after all the other parameters.

For reference, here are all the available form parameters for this endpoint:

r : repository

hasPom - whether you are supplying the pom or you want one generated. If you are uploading a pom, then the parameters g, a, v, p, and c are not needed as part of the command as those values are extracted from the pom.ml

e - extension

g - group id

a - artifact id

v - version

p - packaging

c - classifier (optional, not shown in examples above)

file - each file to be uploaded, use one file parameter per file.

Note: Uploading via the REST API requires that the user has the "artifact upload" privilege in Nexus, in addition to create and update privileges on the target repository.

Uploading Multiple Artifacts at Once

Enable the Nexus Unpack Plugin

In Nexus Professional 2.7.x+, the plugin is already installed by default.

In Nexus Professional 2.6.x and earlier, the optional plugin needs to be installed. You can enable this plugin in earlier versions of Nexus Professional by moving "$NEXUS_HOME/nexus/WEB-INF/optional-plugins/nexus-unpack-plugin-<version>" into "$NEXUS_HOME/nexus/WEB-INF/plugin-repository" and restarting the server.

In Nexus OSS you need to manually install the plugin. Download the bundle.zip which matches your nexus version, and unpack it in $NEXUS_HOME/nexus/WEB-INF/plugin-repository. Then restart the server.

Use the Nexus Unpack Plugin

Once enabled, you can use a REST endpoint to upload zip files via PUT request. This takes the form of (ensure that there is no trailing slash in the URL):

In answer to the first question, it depends on what the application context is set to. In a stock configuration of Nexus we ship with it running on "/nexus".

I'll file a bug for the missing documentation.

Regarding snapshot upload, this is explicitly disallowed by Nexus, the thought is it promotes bad practices. If you need to rely on a snapshot artifact for a long period of time you should rename it as a release:

Programatically uploading a snapshot into nexus requires downloading the maven-metadata.xml file, calculating the next build number, updating the maven-metadata.xml file, uploading it, and uploading the pom and artifact files.

This is doable, but it will add complexity to the upload. And for most use cases, uploading a snapshot manually really isn't the right thing to do. Snapshots are temporary things, usually produced by CI systems, and will likely be cleaned up by the snapshot remover over time. If you really need to depend on a snapshot artifact the recommendation is to rename it to a release GAV.

That said, I think a lot of the concern about this feature is related to UI upload, not necessarily REST API upload. There may be valid use cases to consider here, especially if snapshots are being produced in a CI system by something other than Maven. Is that the case for you?

Thank you for your response. Yes that is essentially my use-case, I am integrating Nexus into a custom build process, and the CI outputs are really "snapshots" in the same sense as Maven's snapshots.

However Maven seems to add a fair bit of additional semantics and metadata to the concept of a "snapshot". This is something I don't fully understand yet, not being a Maven user myself. It seems that most of the difference in Nexus between snapshot and release repos exists to support Maven's model of a snapshot, and so is not needed in my use-case. Therefore a Release repo may simply be the right choice in this case.

Having said that, non-Maven build tools clearly do need the ability to push into Nexus snapshot repos for consumption by Nexus. For example Gradle appears to have a way to do this. I guess that they have probably reversed engineered whatever the mvn:deploy task does. If so, it's a shame that they have to do this rather than using documented, supported APIs.

.I tried this plugin on version 2.8.0-05 and it does not do the thing described here. If I quote Rich:

The files will be unpacked and deployed individually on the server side, just as if they had been individually deployed from a client using standard deploy mechanisms.

This would be very helpful feature for us, because we need to deploy a big amount of artifacts at once and it would be great if the files were deployed as described in your article. When I use your example:

The files are not expanded in /releases/content-compressed/foo/bar/ but in /releases/content-compressed/foo/bar/my.zip

No checksums are created nor maven-metadata.xml files are updated. Is that intentional behaviour?

I suppose Maven will not be able to find artifacts in such "expanded" zip, unless the repository is set directly to the specific zip. Is that right? Is there any way to download the my.zip again in its original (packed) form?

I created a normal zip file with files 'download-manager-2.0.8-javadoc.jar' 'download-manager-2.0.8-sources.jar' 'download-manager-2.0.8.pom' 'download-manager-2.0.8.war' (all directly in root). The war was a web archive I used for experiments with Maven deploys, the pom was a valid pom.xml renamed to this form sources and javadoc were generated by Maven plugins - sources and javadoc. All the files were in the root of the ZIP.

I did not know about the /content-compressed endpoint, this is pretty cool ! Is there, by chance, any way to make this work with the Maven Site plugin and it's deploy goal ? In the olden days, we were deploy sites over ssh, and this was the default behavior: zip up generate site, scp and unzip it remotely. Nowaways, we deploy over dav, and it's a pretty flaky, slow and tedious process, as each file of the site is deployed one by one (which becomes terrible when you factor javadoc in). I'd love to be able to upload zips again.

Does it also have dependency on the edition of Nexus being used ? I have Nexus OSS, I am tryng to use the REST API method to upload artifacts to the Nexus Repository of type "release". But getting the below error.
"HTTP/1.1 405 Method Not Allowed"