Hi guys,
With the object containers, you cannot currently influence how an object is to
be created using the DSL eg.
someContainer {
element1 {
}
element2 {
}
}
Where element1 and element2 are auto created via the existing mechanism. I'd
like to add support for the following…
someContainer {
element1(foo: "bar") {
}
element2(baz: "bat") {
}
}
The idea being that implementations could use the attributes map to influence
how elements are auto created. I think that this is a good capability
generally, but it does make things slightly looser.
For example, what would the default impl do? Would it ignore the properties?
Would it use them to configure the new element by map? Would it throw
UnsupportedOperationException.
The use case I have in mind is where a “native source set” has many outputs, so
something _like_:
cpp {
sourceSets {
main {
// config of where source is
outputs {
main {
// configure how this is to be compiled
}
debug(parent: main) {
// add how to compile a debug variant, inheriting all of the main
settings
}
}
}
}
So cpp.sourceSets.main.outputs is a specialisation of
AbstractNamedDomainObjectContainer with something like…
protected CompileSpec doCreate(String name, Map properties) {
compileSpecFactory.create(name, properties)
}
The key thing here is that this opens up the possibility to create different
kinds of things internally, which is not possible right now because doCreate
_only_ takes a name.
This use case aside, I think this will be a good DSL capability to have. It
will be easy to implement and backwards compatible.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
