On 21/06/2012, at 1:06 AM, Adam Murdoch wrote:
>
> On 20/06/2012, at 6:57 AM, Luke Daley wrote:
>
>>
>> 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)
>
> The plan is the same as last time we discussed it:
> 1. Model publications as things, independent of destination.
> 2. Model signature generation as a transformation of a thing.
> 3. Model conditional configuration using build types.
> 4. Add a plugin that wires the above together in an opinionated way (e.g. all
> publications of type x must be signed).
>
> We really only need 3) to solve the use case, though.
What's the final result here? How are we proceeding?
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
