On 14/02/2012, at 8:21 PM, Peter Niederwieser wrote:
> What are the goals of this work? I thought we just need a simple way for
> users to declare ad-hoc properties in build scripts. If more than that is
> needed (type/transformer/validator/etc.), why not use an extension or
> convention object? I'm afraid that the more dynamic stuff we add, the harder
> it will become to discover and understand the build language, for humans and
> tools alike.
Good points/questions.
The primary problem we have is that creating new properties on demand is far
too loose, as we all know. At the moment we also have no way of doing any kind
of validation or transformation on these properties at setting time. However, I
think this is rarely needed because these kinds of things are usually set once
when they are declared. For the same reason, type checking is probably not that
important either.
So for right now, the absolute priority is to avoid problems like users doing
this: `archiveBaseName = "foo"` and then being surprised that they archives
aren't named as they want. One of the other given design goals was to consider
making adding dynamic properties more open ended so we can add richer features
later.
I think you make a good point though, we should be encouraging the use of
extensions. Perhaps it's good enough to say that for any case where you require
validation/transformation/type checking etc. you need to write an extension
class.
We might however then provide some kind of default extension to all extension
enabled objects that acts like a map. For example, let's say this extension is
named “ext”. So the “ext” space on objects eis where you can add and access new
state. We would keep this completely empty out of the box, in that no plugin or
core feature is allowed to populate or rely on this space. That is, it's purely
for users.
Tasks might look like this…
task doSomeStuff {
ext.foo = "bar"
doFirst {
println ext.foo
}
}
I'm growing fond of this kind of idea. Mainly because it confines the user soup
into one space and makes it visually clear what's been added dynamically. Now
that we are pushing for all extensions to themselves become extension enabled
user's can add state to extensions…
project.signing.ext.passwordFile = file("foo.txt")
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
