On 19/06/2012, at 2:41 PM, Daz DeBoer wrote:
> G'day
>
> I've just added a deprecation warning when there is an attempt to publish an
> artifact that doesn't exist. Previously, we were silently ignoring these
> missing artifacts, which was pretty poor behaviour.
>
> Unfortunately, the Signing Plugin currently depends on this behaviour for
> {required = false}, which means the signing plugin emits the deprecation
> warning when signing is optional and signatures are not generated. More at
> http://forums.gradle.org/gradle/topics/signing_plugin_add_to_configuration_even_if_its_not_being_run.
> This is also causing problems with the Artifactory Plugin, which doesn't
> handle the missing artifacts.
>
> As Luke mentioned, one option would be to add something to the model here:
> the concept of an _optional_ artifact in a configuration, which may or may
> not be present based on other factors.
> Alternatively, we'd need to find a way to ensure that these artifacts are not
> in the configuration when publishing, if they are not actually generated. I
> haven't looked deeply into the plugin to see how this would work.
>
> From here we could:
> 1) Fix the signing plugin now, as part of the unrelated story that triggered
> the adding of the deprecation warning.
> 2) Add a new story to fix the signing plugin, and ensure that it's done
> before 1.1, so we don't release software that emits deprecation warnings in
> normal usage
> 3) Roll-back the deprecation warning and add a new story to fix the Signing
> Plugin and put the deprecation warning back in
>
> I'm tempted to go for 3), since the deprecation warning is trivial to
> add/remove, but the fix is not.
Given that we don't have a solid plan (than I know of) of how to deal with this
concept (something that may be created) I'm inclined to go for 3 as well until
we have that.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
