How do I publish two artifacts with different groups from the same build?

Old Forum Archive
1

I’m writing a Gradle 1.6 plugin to hide a rather unfortunate contract to which I must conform.

Unfortunately it must publish two artefacts from the same build to different groups/groupIds. There is no getting around this. The two artefacts have the same lifecycle and are derived from the same custom DSL in my plugin.

Currently I see no way to do this from within my plugin.

This does not allow group customisation:

artifacts{
   add ("myconfiguration", myFile){
      name = "my-custom-name" //this works fine
      group= "my-custom-group' // this does not work
   }
}

One idea is to create a subproject programmatically in the plugin, but I’m concerned that this might cause problems as there’ll be no project nested directory (though I guess I could create these). Additionally I’m using the Artifactory Jenkins Plugin to do the publishing, so custom publishing configuration in my build is a non-starter.

Any help or ideas much appreciated.

2

With Gradle 1.6, it’s possible to do this using the ‘pom.filter’ attribute of ‘MavenDeployer’. Here’s an example:

mavenDeployer {
            repository(url: file("repo/maven").toURI())
              addFilter('publishing') { artifact, file ->
                artifact.name == 'publishing'
            }
            pom('publishing').groupId = "org.gradlesummit"
            pom('publishing').artifactId = "publishing-talk"
            pom('publishing').version = "3.1"
              addFilter('publishing-api') { artifact, file ->
                artifact.name == 'publishing-api'
            }
            pom('publishing-api').artifactId = "publishing-api"
            pom('publishing-api').version = "3"
        }

Using the latest nightly (or the upcoming Gradle 1.7), you can do this more simply with the new maven-publish plugin:

publications {
        mavenImpl(MavenPublication) {
            from components.java
            groupId "org.gradlesummit"
            artifactId "publishing-talk"
            version "3.1"
        }
        mavenApi(MavenPublication) {
            artifact apiJar
            artifactId "publishing-api"
            version "3"
        }
    }
3

Damn. I just read the rest of your post about using the Artifactory Jenkins plugin: I know that the Gradle ‘artifactory-publish’ plugin interacts well with the new publishing model, but I have no knowledge of the plugin you’re using.

4

@Daz: are you sure about the released version of the artifactory plugin working with the new model?

5

There are now 2 plugins from Artifactory: the ‘artifactory-publish’ plugin uses the new publishing model and I believe is kept up-to-date with any changes. The ‘artifactory’ plugin continues to use the old model.

6

Thanks Daz and Luke. Using the MavenDeployer also assumes a Maven repository, which I admit is normally the case for us, but not always. Oh, and your link returns a 403 for me.

I’ve found a less than ideal, but working solution where by I apply the Gradle Artifactory plugin (old version) in the build.gradle, and my plugin creates a subproject programmatically on a different groupId. I then call “artifactoryPublish” on the programmatically created sub-project from the Hudson Artifactory Plugin.

The real problem here is that the Gradle builds have a dependency on the Artifactory plugin, which I think is wrong. Hudson should be responsible for deploying builds to the repo (IMO), based on what is “published” by the build in a pure Gradle way.

The second problem is that the Hudson job must call artifactoryPublish on a programmatically created sub-project, which is a bit weird for the user of my plugin.