On 11/04/2012, at 12:23 AM, Adam Murdoch wrote: > On 10/04/2012, at 7:49 PM, Luke Daley wrote: > >> http://forums.gradle.org/gradle/topics/signing_plugin_add_to_configuration_even_if_its_not_being_run >> >> The signing plugin adds PublishArtifacts for each signature file. These >> signature files may not actually be created depending on the signing >> configuration: >> >> signing { >> required { project.taskGraph.hasTask("uploadArchives") } >> sign configurations.archives >> } >> >> This “required” handling makes it easy to have a build that works for people >> who don't have their environment set up for signing. If signing is not >> required, and we can't sign, the signing task(s) is skipped so we end up >> with the PublishArtifacts on the configuration pointing to non existent >> files. >> >> The problem comes in that the Artifactory plugin tries to upload these non >> existent files and explodes. >> >> One idea is to allow this as part of the model. That is, a PublishArtifact >> becomes something that might be created during the build instead of >> something that will be created. > > I think the problem here is that the signatures aren't really artefacts, in > the sense that the point of the build is not to generate signatures, the > point of the build is to build the jar or war or whatever it is that is being > signed. Signatures are more like meta-data about artefacts, that are used as > part of shipping the real artefacts around between machines and teams and so > on. > > I would instead think about splitting publications up into 2 pieces: > * The definition of the component that is being produced. This defines the > artefacts that are fundamental to the component that always need to be build: > the jar or the dll or the distribution zip or whatever. > * The definition of the destination-specific publication. This defines the > artefacts that will be published to the given destination, where destination > is a repository. This would (by default) include the artefacts of the > components being published. It might also include signatures or checksums or > meta-data artefacts or whatever additional artefacts need to be published to > this destination. > > This way, there's no need for conditional signing or PublishArtifacts. If you > are building locally, the signing is not triggered. If you've declared that > signatures are required to publish to the corporate repository, then you need > to have signing set up if you want to publish there and its a failure if you > don't.
I'm not sure about expressing the requiredness of something purely as a function of where it's going. That's too rigid in my opinion. One example is that you may want to say that signatures are only required if we are doing a final release, and you may not be using separate destinations for final and non-final releases. I think it's much safer to allow the user to control this for whatever case they need. We can apply patterns over the top of course. Also, rather than destination-specific publications I think we should be aiming for aggregate & filtered publications which can then be used in whichever way the user wants. Tying it to a destination seems like inflexible coupling to me. I agree that we need to be able to model metadata, but I think that's an entirely separate issue. It's feasible to me that the build might not produce first class artifacts under certain conditions and that being ok. You can do this right now of course by never modelling the optional thing if we aren't going to make it, but that implies that you can make the decision reasonably early which may not be the case. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
