On 22/02/2011, at 2:54 AM, Hans Dockter wrote:
>
>
> On Mon, Feb 21, 2011 at 2:13 AM, Adam Murdoch <[email protected]> wrote:
>
> The Configuration type and the configurations { } script block would be
> removed. The DSL for declaring dependencies would stay pretty much the same
> as it is now:
>
> repositories { ... }
>
> dependencies {
> compile 'some:dep:1.0'
> }
>
> You will be able to declare custom dependency sets, similar to declaring
> custom configurations now:
>
> dependencies {
> custom { transitive = false; description = 'some configuration' }
> }
>
> How can we distinguish between reconfiguring an existing dependency set
> versus declaring a new one?
A good question. I think this is a separate topic, however. At the moment, the
pattern we use in the DSL when configuring a container of domain objects is to
implicitly create the domain objects when they are mentioned. This only happens
in a configure closure, so 'sourceSets { custom }' will add the custom source
set if it does not exist, but 'sourceSets.custom' will not.
I think if we want to change this pattern, we should change it everywhere.
Ideally, this would include tasks, too.
Some options for explicit declaration:
* Use a factory method
sourceSets {
custom sourceSet { ... }
}
myZip zip { .... }
* Use assignment and factory method:
sourceSets {
custom = sourceSet { ... }
}
customTask = zip { ... }
* Use local var definitions and factory method:
sourceSets {
SourceSet custom = sourceSet { ... }
}
Zip customTask = zip { ... }
* Use a keyword:
sourceSets {
sourceSet custom { ... }
}
zip custom { ... }
or a generic keyword
sourceSets {
define custom { ... }
}
define custom(type: Zip) { ... }
* Use an add method:
sourceSets {
sourceSet(name: 'custom') { .... }
}
task(name: 'myZip', type: Zip) { ... }
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
