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

(John Engelman) #1

From this posting:

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

As per:

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().

(Luke Daley) #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.

(John Engelman) #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.

(Peter Niederwieser) #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.

(Endre Stølsvik) #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:

(Peter Niederwieser) #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.