Preferred way to publish snapshots/releases to Artifactory?

Help/Discuss
1

There are at least 3 commonly used plugins to publish artifacts to Artifactory:

I’d like to publish snapshot artifacts to a snapshot repository (e.g. libs-snapshot-local) and release artifacts to a release repository (e.g. libs-release-local).
I’d also like to be able to specify the version for the artifacts via a parameter for the buildscript.

Which plugin is recommended for this scenario? Is there an example configuration available somewhere?

I’ve used the Gradle Artifactory plugin in the past, but found it quite cumbersome and verbose to configure it properly.

The maven-publish plugin has been incubating forever, but since it still seems to be the successor of the original maven plugin, I gave it a try. Unfortunately, it only seems to work if you configure it with static info (group, artifact id, version, …). If you want to configure something dynamically, it barfs out with “Cannot configure the ‘publishing’ extension after it has been accessed.”. I did not manage to find a solution for that.

I’ve not used the old maven plugin before, because I expected it to go away. What are the plans for this one?

Also, I think what I’m trying to do is very standard, so it should be easy to configure. However, neither the Gradle docs nor the Artifactory docs provide an example for it.

I’d really appreciate it if someone could provide some insight on this.

Thanks,

Glenn

2 Likes
2

I managed to get it to work with the maven-publish plugin, but it’s definitely a quirk in the plugin.

This does not work:

apply plugin: 'maven-publish'
apply plugin: 'application'

group = "com.mycompany"
version = project.properties.containsKey("releaseVersion") ? "${releaseVersion}" : "0.0.1-SNAPSHOT"

project.ext {
    artifactoryRepo = project.properties.containsKey("releaseVersion") ? "libs-release-local" : "libs-snapshot-local"    
}

publishing {
    repositories {
        maven {
            credentials {
                username "${artifactoryUser}"
                password "${artifactoryPassword}"
            }
            url "${artifactoryUrl}/${artifactoryRepo}"
        }
    }
    
    publications {
        myPublication(MavenPublication) {
            artifact source: distZip, extension: "zip"
            artifact source: someOtherDistZip, classifier: "dumdeedum", extension: "zip"
        }
    }
}

But this if you change “publishing” with “publishing.repositories” and “publishing.publications”, then it does work:

apply plugin: 'maven-publish'
apply plugin: 'application'

group = "com.mycompany"
version = project.properties.containsKey("releaseVersion") ? "${releaseVersion}" : "0.0.1-SNAPSHOT"

project.ext {
    artifactoryRepo = project.properties.containsKey("releaseVersion") ? "libs-release-local" : "libs-snapshot-local"    
}

publishing.repositories {
    maven {
        credentials {
            username "${artifactoryUser}"
            password "${artifactoryPassword}"
        }
        url "${artifactoryUrl}/${artifactoryRepo}"
    }
}
    
publishing.publications {
    myPublication(MavenPublication) {
        artifact source: distZip, extension: "zip"
        artifact source: someOtherDistZip, classifier: "dumdeedum", extension: "zip"
    }
}

There are some other posts about the same problem:

1 Like
3

In our company we solved that by using several jenkins build jobs for each project. Here is another thread about this:

4

Just some more info: besides setting the repo you might also want to change the behavior. If you tack on “-SNAPSHOT” to your project.version then the new plugin will create the “goop” at the end of the version number that can uniquely define a particular build. This allows projects that depend on this project to depend on latest / + version. Also means that you can specify your artifactory does not allow overwriting the same artifact with the same version number. If you don’t put he “goop” on you either have to allow overwrites, figure out some goop code on your own, or force version updates with every commit - all of which are not particularly good ideas.