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 “http://10.144.5.3:8081/nexus/content/repositories/publishedSnapshots”
}
}
} ’
As far as I know, non-unique snapshots aren’t supported. Maven 3 no longer supports them either.
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: ‘sas-installation-1.1.0-20130410.145638-1-windows.zip’
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.
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.
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?
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 "http://10.144.5.3:8081/nexus/content/repositories/publishedSnapshots"
}
}
}
}
...
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){...
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.
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.
Pruning the repository is the repository manager’s job. Pruning the Gradle cache is a planned feature.
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.
The comment didn’t get lost. See my answer above.
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.
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.
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
In Artifactory, there is a “max unique snapshots” setting per repository. I’d expect Nexus to offer a similar feature.
@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.
This was split into a separate post: http://getsatisfaction.com/gradle/topics/maven_publish_plugin_publishes_snapshot_versions_to_mavenlocal_using_setunique_true