On 09/11/2011, at 1:40 AM, Adam Murdoch <[email protected]> wrote:
> On 08/11/2011, at 1:32 AM, Luke Daley wrote:
>
>> This doesn't compile:
>>
>> artifacts {
>> default someZip
>> }
>>
>> It needs to be:
>>
>> artifacts {
>> delegate.default someZip
>> }
>
> Or artifacts { 'default' someZip }
That will compile, but doesn't do the same thing. To use strings as method
names there must be an explicit target, so that would have to be
delegate.'default' which isn't better.
>> Given that now default does not extend archives, meaning that manually
>> adding something to the default configuration is going to be likely, I think
>> we need to rename this.
>
> It depends on what its purpose is. If you want to add a jar to be used at
> runtime, you'd simply add the jar to the runtime configuration.
If I am not applying the java configuration because my project produces a zip
of documentation and not a jar then 'default' is the best choice. I have this
case in the Geb build where I use a project dependency somewhere else for this
kind of project.
> I want to get rid of the idea of a default configuration at all. The
> (default) configuration that is used by the consumer should instead be a
> function of what the consumer is trying to do. If they're compiling java
> code, we should use 'api' (say). If they're running code on the jvm, we
> should use 'runtime'. If they're assembling an ear, we should use
> 'ejbComponents'. And so on.
I still think there is a case for a "default" like configuration for cases like
mine where there are no conventions.
So we could either force the user to create a producer/consumer convention, or
have a default fallback as we do now (but rename it).
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
