On Nov 7, 2008, at 9:33 PM, Adam Murdoch wrote:
Hi,
I wonder if we should generalise the extension mechanisms we have
in Project (additional properties, extension using convention
objects, and inheritance) and apply them to Task.
I've found using convention objects to add behaviour to projects to
be extremely useful in my own builds and plugins. I imagine the
same would be true of applying them to tasks as well (and possibly
a few other common types, such as Settings and DependencyManager).
This is an excellent idea.
I would also like to review the way the convention mechanism is
implemented at the moment.
In addition, I think consistency is important here. Settings,
Project and Task all have dynamic properties and/or methods, but
they all work a little differently, and the methods on the
interfaces are not quite the same (setProperty vs defineProperty).
I'd rather not have to keep a different set of rules in my head for
each type of extensible thing.
Definitely. But we have run into a Groovy pecularity here. For any
Groovy object setProperty is automatically added. You can overwrite
this but this gets not inherited. Therefore the way we use it works
for projects, as we only use the default project. But it does not
work for tasks as the tasks inherit from DefaultTask where
setProperty is overwritten. So I guess we have to rename the
setProperty method of the Project class.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
