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.
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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
