ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Date Sat, 18 Feb 2012 23:03:11 GMT
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 

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.
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