ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mansour Al Akeel <>
Subject Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Date Sat, 18 Feb 2012 23:30:04 GMT
On Sat, Feb 18, 2012 at 6:03 PM, Bruce Atherton <> wrote:
> I have similar thoughts on the high level abstract view of Ant. Here is how
> I see it:
> 1. Command Line Processor
> 2. Build File Parser
> 3. Dependency Tree Resolver
>    - This is essentially a Dependency Injection/IOC system, but with late
> binding (Unknown Element) and modification through things like macros done
> in later phases
> 4. Dependency Analyzer
>    - Generates the queue of ProjectComponents to execute incrementally based
> on if/unless and dependencies
> 5. Execution Engine
>    - May call back into 2, 3, or 4
> 6. Monitoring System
>    - logs, BuildEvents, etc)
> Note that this is just conceptual and not reflecting how things are actually
> implemented in Ant 1.
> As I understand Gilles suggestion, he'd like to see something more like
> this:
> 1. Command Line Processor
> 2. Build File Parser
> 3. Translation into State Machine
> 4. Execution of State Machine
>    - This can modify itself as it processes. This would include resolving
> UnknownElement, deleting transitions based on if/unless, allowing the
> altering and additions of transitions to control new dependencies, inserting
> macro subtrees, parsing and adding new build files, etc, etc.

How easy is't to unit test additional plugins. When you rely a lot on
context, you need to create a similar context for testing.
Is't going to be easy ? Writing and testing tasks independently will
allow a lot of plugins to exist.

> 5. Monitoring System (logs, BuildEvents, etc)
> This design looks a lot simpler to me than the first one. As I think about
> it more I'm starting to like it.
> As for automating parallelism, if you know what resources are needed and in
> which state, and you know which ProjectComponents will get the resources
> into that state for you, then it is possible for an application to determine
> which ones can run in parallel rather than sequentially. Obviously there is
> a lot of handwaving in there.
> On 2/18/2012 1:13 PM, Mansour Al Akeel wrote:
>> Bruce,
>> The current design is simple, and proven successful and easy to
>> maintain. Here's a quick pseudo:
>> 1- parse the build file, initializing all the "DataStructures" and
>> references to the tasks and macros. Populate them all to the running
>> context. Maybe OSGI has something like this.
>> 2- if there's sub modules declared then do the same, and populate them
>> all the current context, adding name space to the references for the
>> tasks in the sub modules. For example assuming the current project has
>> a task called "build", then the one for the sub module will be
>> "submodule1:build". (assuming you want multi module support built-in
>> and not added by an OSGI bundle).
>> 3- If you want parent project support then we can do the same.
>> 4- Depeding on the task called, execute the corresponding task and
>> pass it an object of the Data Structure you want to process. The
>> reason for this is to make it easy to unit test it.
>> 5- additional tasks and dataType can be added through OSGI bundles.
>> For example, let's say I want a task to compile a war file, I can just
>> extend the dataStructure (TypeDef, or any other name), with default
>> values. Write my task, and test the execute method by passing it a
>> reference to my WarDataStructure. Initializing a task requires only
>> the path to the current directory. So instead of passing an object of
>> type (Project), I will just it a path, and it knows the path it should
>> execute in. (This is for multi module).
>> 6- A generic data structure can be used (ie, hashmap) and passed to
>> execute method. This has a copy of all the data initialized in the
>> build file.
>> 7- I am not sure what you mean by parallelism, but I am assuming
>> running more that one task at the same time. This can be added through
>> bundles, but then again, we will run into the same issue like Gradle.
>> If you want a task to run continuously on even (ie, a file change),
>> then you have to write a different task to do so, as parallelism
>> requires a flag to tell if a task has been executed or not. I think
>> the way ant doing it already is the best (ie. using<parallel>).
>> Trying to keep the core as simple as possible, will make maintenance
>> easy, and prevent bugs. Once a bundle proven useful and required
>> always by the users, then it can be merged with the core.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message