Thanks for the reply Wouter. What you’ve said above makes sense and is well documented in the gradle user’s guide for multi-projects and/or projects which create multiple artifacts and use filters in the uploadArchives section.
In the last example from swpalmer (assuming I understood his post correctly) and in my example, there is only a single artifact and the project is not a part of a multi-project build. It is just a simple project which creates a zip and attempts to upload it to Nexus with a generated pom file. While I can see that a pom file is generated (build/poms/pom-default.xml) and the generated pom appears to be correct (it even includes the packaging attribute indicating a zip artifact), the pom is simply ignored during the upload phase to Nexus.
Nexus is a pretty clever pony, and I thought, perhaps, that Nexus was ignoring or discarding the pom that was being supplied by Gradle. Examining the debug output generated from the Gradle build, I can see the PUT requests generated for the zip artifact and there is no corresponding PUT for the pom file. For some reason, Gradle is choosing not to upload the generated pom.
I’ve discovered another side-effect. The SNAPSHOT artifacts which are being uploaded to Nexus are not being assigned unique versions. That is, they all have versions like 1.0-SNAPSHOT rather than the expected 1.0-20120229.1234456.zip.
I have other projects which upload both a zip and a jar and, this those projects, the pom is uploaded and all artifacts have the “SNAPSHOT” portion of their version replaced with a timestamp.
I’ve included the
uniqueVersion = true
in my uploadArchives.repositories.mavenDeployer definition, and still no version replacement.
I’ve also noticed that there is no install task defined. That is:
>
gradle install
FAILURE: Could not determine which tasks to execute.
* What went wrong:
Task 'install' not found in root project 'testing'.
* Try:
Run gradle tasks to get a list of available tasks.
BUILD FAILED
Total time: 0.403 secs
This leads me to think that there might be some issue with the way the maven plugin in being configured since, according to the maven plugin docs, the maven plugin should be generating an install task associated with the archives configuration.
I wonder if the root issue could be resolved by some missing maven configuration.
As far as I can tell, these problems only exist when using the Maven plugin without the Java plugin. Otherwise, POMs get uploaded fine, and snapshots have unique versions by default. The situation will improve once we revisit artifact publication. We have a lot of plans to make this better and more powerful than what it is today.
It seems that adding a classifier to an archive task results in the related upload task skipping the upload of the generated pom file and replacement of “SNAPSHOT” with a timestamp on the artifact.