Maven uniqueVersion for publishing

(david koch) #1

Hello, I use the new publishing feature in order to publish artifacts. It works great so far. But it seems to publish SNAPSHOTs with the unique version feature.

Is it possible to switch it of while still using this code: ’

publishing {

repositories {

maven {

credentials {

username “admin”

password “admin123”


url “



} ’

(Peter Niederwieser) #2

As far as I know, non-unique snapshots aren’t supported. Maven 3 no longer supports them either.

(david koch) #3

I wouldn’t like it either. But when publishing to nexus and even to a directory with: 'maven {

url “./build/repo” }’

I get always artifacts that look like this: ‘’

(Peter Niederwieser) #4

That’s what a unique snapshot looks like. You’ll only get a file ending in ‘-SNAPSHOT’ when you publish to the local Maven repository. I believe that the ‘publishToMavenLocal’ task already honors this.

(david koch) #5

In my case both taks - publish and publishToMavenLocal - perform well and consistent but unfortunately with that nasty unique version feature. This means also that nexus is not involved in it as expected.

(Peter Niederwieser) #6

What do you mean by “nexus is not involved in it as expected”? As I said, even Maven 3 will always produce unique snapshots, and Nexus deals fine with them. What problem are you trying to solve? Why do you want non-unique snapshots?

(david koch) #7

Perhaps some code would be good. The repository config I do in the root build file like this:

afterEvaluate {project->
          if(project.plugins.hasPlugin('maven-publish')) {
      publishing {
        repositories {
          maven {
            url ""

The concrete publishing config is done in the according components build file:

apply plugin: 'maven-publish'
  publishing {
  publications {
    mavenJava(MavenPublication) {
      artifact buildInstallation
  task buildInstallation(type: Zip){...

(david koch) #8

The reason not to have unique versions is that it heavily consumes disk space on my narrow-chested build machine (vm) for nothing. It builds lots of times a day. The installation artifact consumes around 130 MB just for trying out it is buildable and publishable. There is no consumer for this. Every build add new artifacts to disk with no use. And in order to get rid of it I need another job somewhere which adds more complexity than I need.

But on same time I wouldn’t like to not publish the snapshot because I wouldn’t see if the publish task fails.

(david koch) #9

If there would be a feature like “keep the last x snapshot versions” this would also be great. I would rather like to keep publishing and repo maintenance within the build scripts than to spread it over lots of tools like jenkins or nexus.

(Peter Niederwieser) #10

Pruning the repository is the repository manager’s job. Pruning the Gradle cache is a planned feature.

(david koch) #11

Somehow the first of my comments got lost.

My actual problem is that the installation artifact which is produced by the build weighs ca. 130MB. Its quite a lot if the build creates 20 times a day or oftener 130 MB just for checking that it works.

I’ve no consumer which uses the snapshot build its just there to see that everything including publishing still works. In this case the history is completely useless. Now I must somehow create a clean-job in order to get rid of things I have no use for.

But I don’t want to not-publish because than I don’t get the feedback if something goes wrong.

(Peter Niederwieser) #12

The comment didn’t get lost. See my answer above.

(david koch) #13

Pruning is ok if necessary but it increases complexity for the CI setup. In this case its just a small project. I would like it to just not to create things I don’t need. The very one copy is just required in order to prove publishing works. So its quite probable it works also for releases which are quite seldom in this case.

(Peter Niederwieser) #14

Activating pruning in your repository manager (whose installation you need to maintain anyway) should be as simple as ticking a checkbox. Not sure if Maven repository pruning can be implemented generically on the client side in a way that’s compatible with common repository managers. Maybe someone wants to give it a try and develop a pruning plugin.

(david koch) #15

This is not quite satisfying me. I found no checkbox for this simple task in my repo manager (nexus). Even if nexus had such a checkbox it would be required per artifact. And whats about a file-repo? But I found a good solution for my problem. I just don’t use the SNAPSHOT tag. Instead I tag it otherwise like DEV. It does anything I need. And its so simple. Anyhow, thanks a lot for the answers. David

(Peter Niederwieser) #16

In Artifactory, there is a “max unique snapshots” setting per repository. I’d expect Nexus to offer a similar feature.

(John Engelman) #17

@Peter - In my setup with with the maven-publish plugins, SNAPSHOT versions are being published to MavenLocal() with uniqueVersion = true.

I don’t think this is the correct behavior.

The problem is that the PublishToMavenLocal task extends the PublishToMavenRepository which creates an AntTaskBackedMavenPublisher which creates CustomDeployTask and sets uniqueVersion = true. This is causing issue with other tools that rely on Maven dependencies like Grails, because they expect MavenLocal to have uniqueVersion = false.

(Luke Daley) #18

This was split into a separate post: