Install task is depending on unrelated signing task

Old Forum Archive
1

I’m publishing to maven central in an open source project, which means I need developers to be able to “gradle install” locally and while also exposing a release process which will sign and upload to sonatype. The problem is that the install task is trying to sign the artifacts, which is problematic because those users don’t have all the signing.* properties defined, so the signing task errors out with a “Signatory not found” error. I know I can set required=false on the signing plugin, but I want to more intelligently separate these two processes.

My idea was to create a new configuration which will have the signatures:

configurations {
        signatures {
            extendsFrom archives
        }
    }

Then I sign only that configuration:

signing {
        sign configurations.signatures
    }

Then I have a custom Upload task to handle the upload to sonatype based on only that configuration (abbreviated):

task uploadMavenCentral(type:Upload) {
        configuration = configurations.signatures
        dependsOn signSignatures
        repositories.mavenDeployer {
            beforeDeployment { org.gradle.api.artifacts.maven.MavenDeployment deployment -> signing.signPom(deployment) }
              repository(url: 'http://oss.sonatype.org/services/local/staging/deply/maven2/') {
                authentication(userName: rootProject.sonatypeUsername, password: rootProject.sonatypePassword)
            }
       }
    }

That setup, to me, should have let the install task (which explicitly depends on the archives configuration) run without running signSignatures (task created by the signing plugin for the configurations which are stated to be signed). Yet, that’s not true. The install task is running signSignatures even though it has nothing to do with it’s configuration. Any ideas?

The debug output is, um, deficient in helping me understand why there is a task dependency here. The only feedback I can get without debugging is running “gradle tasks --all” which shows dependencies (in brackets) and “children” (indented below). What are “children” in the context of the TaskReportPlugin? I can’t find any reference to it in the docs and it seems critical in trying understand why I’m getting signSignatures as a dependency. For example, what is the difference between the two types of dependencies in the output below:

curator-client:install - Does a maven install of the archives artifacts into the local .m2 cache. [curator-client:classes, curator-client:jar, curator-client:javadoc]
    curator-client:javadocJar
    curator-client:signSignatures
    curator-client:sourcesJar

Is it dependsOn vs outputs/input dependency? It would be amazingly helpful to know WHY one task depends on another. As projects get more complicated or you jump into a new gradle project which you’re unfamiliar, this is critical to know how the DAG is constructed and not just what it looks like.

2

A simple solution is to only sign when the upload task is going to be executed. See conditional signing in the user guide.

3

As Peter said, conditional signing will be simpler.

BTW, the signing plugin creates a configuration called “signatures” itself that it places the signature artifacts on to (not the artifacts to be signed). You might want to choose a different name because of this.

As for why you see the behaviour you do…

The ‘install’ task is configured to install the ‘archives’ configuration. The ‘archives’ configuration is a special configuration that holds all publish artifacts for the project. Therefore it’s going to contain the signatures no matter how you arrange the configurations.

To achieve what you want, you need to install a different configuration. If you are only installing the main jar, you can use ‘runtime’.

install {
  configuration = configurations.runtime
}

If you’ve got source and javadoc jars you’ll have to do a bit more…

configurations {
  installable.extendsFrom runtime
}
  artifacts {
  installable javadocJar, sourceJar
}
  install {
  configuration = configurations.installable
}
4

Thanks. That really helped me understand some of the configurations issues that I’ve been having.