On Sat, Feb 18, 2012 at 6:03 PM, Bruce Atherton <br...@callenish.com> 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: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
