0
votes

I have a company-specific Nexus server version 3 running here; I've uploaded a snapshot version of one jar which is dependency to another project. We use Gradle 3 for building and uploading. On the nexus browser I can see the Snapshot jar file, its .pom file and the metadata xml files are there too.

From the debug output in Gradle I can see that the [project]/[version]-SNAPSHOT/maven-metadata.xml was received and processed, because it then tries to find the most recent jar file by constructing a timestamp-version name from the data in the xml file.

Gradle then tries to GET the .pom and the .jar file from nexus with an URL like [project]/[version]-SNAPSHOT/[project]-[version]-20161212.012547-3.pom and Nexus returns 404. The same happens for the related jar file.

I took the url from the log into a browser and the 404 status is returned as well. changing the url, so that it says [project]/[version]-SNAPSHOT/[project]-[version]-SNAPSHOT.pom then I get a 200 OK plus pom file, and the same accordingly for the jar file.

So I wonder now, is this a bug in the Gradle Maven repository handling, the Nexus 3 server or the gradle build file?

1

1 Answers

0
votes

I don't think this is an issue with Gradle nor Nexus Repository per se, and more so just an issue with the workflow. It SOUNDS like the client doing the deploy is deploying non timestamped snapshots. If that's the case, whatever client is doing the deploy should just be switched to using timestamps instead of non timestamped.