On Apr 16, 2009, at 12:35 PM, Adam Murdoch wrote:
Hi,
I'd like to extract a TaskContainer interface from Project. It would
look pretty much the same as ConfigurationContainer. Some reasons why:
- To move some of the noise on Project to other interfaces
- To make the APIs for collections of tasks, configurations,
repositories (and source dirs, test suites, etc) more consistent.
- To share more of the container-of-domain-objects code that is
currently scattered in various places, as, say, an abstract super
class. This makes it easy to add new capabilities to all
collections, and to add new types of collections.
The following task-related methods would be removed from Project,
and replaced them with equivalents on TaskContainer:
- findTask(name)
- task(name)
- task(name, closure)
- getAllTasks(recursive)
- getTasksByName(name, recursive)
- getTasks()
- addTaskLifecycleListener()
- whenTaskAdded()
That makes a lot of sense. The project class has grown too big (and
its test as well).
I'd leave the following methods:
- createTask(...)
Also, the current dynamic behaviour of Project would remain, ie
- can access a task a as property of Project
- can configure a task using task name + closure
TaskContainer (and ConfigurationContainer, and RepositoryContainer)
would allow tasks to be accessed as properties, and would also allow
indexing, eg
tasks.someTask.srcDir = ...
tasks['someTask'].srcDir = ...
Then some of the functionality of the DSL handler classes (e.g.
RepositoryHandler) would be obsolete.
FWIW: I have run into issues with naming a method 'get'. Groovy uses
get() to overload the dot operator. If a Java class implements the get
method for a non overloading purpose and a Groovy class inherits from
the Java class, this will cause problems.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
