Hans Dockter wrote:
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.
Heh, it sure does :)
So, I'm not sure what to do with this. Some options:
- Change get() to throw MissingPropertyException for an unknown
task/configuration/repository.
- Rename get() to something else. getByName()? getWithName()?
withName()? We should also rename find() if we rename get().
I don't really like either option. Any other ideas?
Some other questions/issues:
Should we rename get(Spec) on the containers to findAll(Spec)?
Project.findTask() and task() accept a task path (ie can be a name, a
relative path, or an absolute path). The containers' find() and get()
methods currently accept a name only.
Should we change the containers to accept paths? Leave things as they
are? Add some different methods to the containers which accept paths,
such as getByPath(), findByPath(), etc?
Another option would be to add a new interface which allows
cross-project lookup. This could also be the home for the recursive
versions of Project.getAllTasks() and Project.getTasksByName()
Thoughts?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
