Maven-publish plugin publishes snapshot versions to mavenLocal using setUnique(true)

Old Forum Archive
1

From this posting: http://forums.gradle.org/gradle/topics/maven_uniqueversion_for_publishing

The PublishToMavenLocal task uses the default CustomDeployTask created by AntTaskBackedMavenPublisher which sets uniqueVersion = true. This is incorrect for publishing to mavenLocal:

As per: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments

Non-unique Snapshot Deployments The setting false for a distribution repository has no effect in version 3.x, snapshot artifacts will always be deployed using a timestamped version.

The uniqueVersion settings only has no effect for a ‘distribution repository’ which I don’t believe applies to mavenLocal().

2

Is there any way you could verify this with Maven? I think you’re right, but there’s a bit of room for interpretation in their language.

I’d prefer to have a little bit more evidence before we make the change.

I’ve raised GRADLE-2762 in the expectation that you’ll prove to be right on this.

3

I updated the JIRA ticket with a maven project and the results I found. I’m not a maven expert but any means, but I used the Maven Shade Plugin project, updated the version to end in ‘-SNAPSHOT’ and ran ‘mvn install’ which installed the jar as non-unique.

4

Installing into the local Maven repository definitely needs to add a non-unique snapshot. (This allows tools such as IDEs to pick up new snapshots simply by refreshing the file.) Only question is if it should also add a unique snapshot. From what I remember, some Maven versions do. Not sure if they also prune old snapshots.

5

I need a workaround!

How can I set set uniqueVersion = false to get a SNAPSHOT version, not the replace-SNAPSNOT-with-a-timestamp version?

(Off on a tanget: It is apparently just a direct match-on-end-of-string, if I use “1.0-XNAPSHOT”, it is not uniqueified).

Needless to say (I assume!) I put my zero-worth vote on the table for this bug to be fixed by the 1.7 release! :slight_smile:

6

One workaround is to use the existing, non-incubating “maven” plugin. Another workaround is to write some code that renames the file after Gradle published it. I’m not aware of an easier solution.

1.7 is already in the RC phase, so a fix will have to wait for a later version. (We have a strict rule to only fix major regressions in RCs.)

(Off on a tanget: It is apparently just a direct match-on-end-of-string, if I use “1.0-XNAPSHOT”, it is not uniqueified).

That’s how Maven version numbers work.