I was thinking about doing something to make the blocks that we provide in
the build file (repositories, configurations, dependencies) more
general/flexible. This is probably not as related to what you were bringing
up Adam but it just came to my mind when reading ConfigurationContainer :))
. Currently this is something that seems to static to me. Wouldn't it be
cool if plugins would be able to add blocks?
Not sure about how to name this but for now I'll call it
ConfigurationContext ( I'd use ConfigurationContainer but that is already in
use). This would be a parent interface for the current
ConfigurationContainer, ... . And we'd add configuration contexts to a
project making the configuration context that are available dynamic. This
way it would be possible for plugins to add blocks ( environments, ...).
Some implementation thoughts:
ConfigurationContextName would be a marker interface.
ConfigurationContext would have 2 methods:
ConfigurationContextName getName();
void configure(Closure)
An implementation would provide a enum constant as name and implement the
configure method
public class Environments implements ConfigurationContext {
public enum Name implements ConfigurationContextName { //
this is just to make sure that we don't use strings when we want to reffer
to a block in code.
environments
}
public void configure(Closure configureClosure) {
ConfigureUtil.configure(configureClosure, this) //
extracting this from default project would be good I think as we probably
will keep adding blocks
}
}
Project would have a Map<String, ConfigurationContext> with String being the
toString value of a ConfigurationContextName. It would use this map in
methodMissing when the method name matches and the only parameter is a
Closure and call configure on the ConfigurationContext.
get${ConfigurationContextName} should return the ConfigurationContext.
I think this will allow us to keep Project leaner in the future.
2009/4/16 Hans Dockter <[email protected]>
>
> 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).
absolutely
>
>
>
>>
>> I'd leave the following methods:
>> - createTask(...)
>
> Perhaps it would make sense to put this in the default
ConfigurationContext?
>
>>
>> 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
>
>
>
