Bug report for Ant [2012/02/19]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 5003|Opn|Blk|2001-11-21|exec task does not return after executed command f| | 6606|Opn|Enh|2002-02-21|META-BUG problems with delegating classloaders| | 7712|New|Enh|2002-04-03|Provide patternset support for VSSGET task? | | 8294|New|Enh|2002-04-19|: Allow and to app| | 8866|New|Enh|2002-05-07|Signal handling in java task | | 8895|New|Enh|2002-05-08|ant and/or antcall should support forking | | 8972|New|Enh|2002-05-10|allow property expansion in property v| | 8981|New|Enh|2002-05-10|Tar task command additional features | | 9294|New|Enh|2002-05-21|[PATCH] optional/j2ee/ServerDeploy OC4J Support | | 9784|New|Enh|2002-06-11|BuildNumber task: make more extendable... | | 9995|Ass|Enh|2002-06-19|MKS Source Integrity tasks| |10020|New|Enh|2002-06-19|'s dependency behaviour should be more con| |10231|New|Enh|2002-06-25|Need access to current file in SQLExec| |10283|New|Enh|2002-06-27|Add a destfile to the uptodate task | |10402|New|Enh|2002-07-02|adding the ability of html like whitespace preserv| |3|New|Enh|2002-07-24|keytool task | |11560|Opn|Enh|2002-08-08|Taskdef does not apply reverseLoader policy on sta| |12267|New|Enh|2002-09-03|Add ability to unzip into separate folders| |12292|New|Enh|2002-09-04|[PATCH] enable tag inside tar| |12334|New|Enh|2002-09-05|REQUEST: Ant task doesn't allow attachment of a bu| |12518|New|Enh|2002-09-11|Gunzip & BUnZip2 add filesets, patternsets, and ov| |12765|New|Enh|2002-09-18|"rmdir" and "deltree" patches for ftp task enhance| |12964|New|Enh|2002-09-24|ANTLR only takes one input file at a time | |13047|Inf|Enh|2002-09-26|Support for and on O| |13048|New|Enh|2002-09-26|Add an optional containsall attribute to LineConta| |13371|New|Enh|2002-10-07|[PATCH] Contributed new CvsExportDiff task| |13847|New|Nor|2002-10-22|pvcs task: wrong option (-r) specified for get (sh| |13934|New|Enh|2002-10-24|Translate task shouldn't load default locale prope| |13939|New|Enh|2002-10-24|Translate task should have better key matching cap| |14320|New|Enh|2002-11-06|copy fileset followsymlinks="false" does not copy | |14393|New|Enh|2002-11-08|Support use of jndi within ant| |14512|New|Enh|2002-11-13|Allow creating database connection similar to with does not spot bad symlin| |15149|New|Enh|2002-12-06|Replace task | |15244|New|Enh|2002-12-10|tar task should be able to store symbolic links as| |15430|New|Enh|2002-12-17|Enhancement to ReplaceRegExp.java | |15596|New|Enh|2002-12-21|Identity mapper in uptodate task. | |15729|Ass|Nor|2002-12-31|StarTeam rootLocalFolder should be java.io.File | |15747|New|Enh|2003-01-01|change tasks (e.g. Ant) to take urls as well as fi| |15853|New|Enh|2003-01-07|Allow to plug-in different XML Catalog resolver in| |15949|Opn|Enh|2003-01-10|please provide links to docs.xml and jakarta-site2| |16131|New|Enh|2003-01-15|not possible to suppress "BUILD SUCCESSFUL" messag| |16255|New|Enh|2003-01-20|XmlLogger without DOM tree| |16427|New|Enh|2003-01-26|Output return value of setLastModified/document be| |16469|New|Enh|2003-01-27|Apply task should allow parallel execution on diff| |16494|New|Enh|2003-01-28|[PATCH] accessibility of Ant documentation| |16562|New|Enh|2003-01-29|Can not accept characters from keyboard in a thre| |16860|New|Enh|2003-02-06|Silent or Debug a single target | |16896|New|Enh|2003-02-07|Support in ProjectHelper / ProjectHelperImpl to op| |17074|New|Enh|2003-02-14|Contribution for WLSTOP | |17181|New|Nor|2003-02-18|Build fails while trying to get VSS files by label| |17372|New|Enh|2003-02-25|Enhancement of replace Task | |17742|New|Maj|2003-03-06|PVCS task generates GET with promotion group incor|
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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). >> >> 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
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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). 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
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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 ). 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. On Sat, Feb 18, 2012 at 2:48 PM, Bruce Atherton wrote: > Of course you are right, and initially parallelism and distributed builds > will probably not be in the initial alpha release (unless it is on someones > scratching list). Just getting something to run existing build files > reliably will be fine. > > But you have suggested that we tag build files that require Ant 2 features > with something that identifies them as requiring Ant 2. I think this is > reasonable for the leap from Ant 1 to Ant 2, but one thing HTML has shown is > that version numbers are an anti-pattern, which is why the DOCTYPE for HTML5 > has done away with them (although that introduced its own "version" ie. no > version). What is important is the list of features that are needed to > interpret and run the file correctly. > > One can imagine a version tag listing Ant 2 as a minimum for a build file > with an attribute for a comma separated list of the features that are > required from Ant for the build. With this and the kind of packaging system > that OSGI and possibly Java 8 will introduce, Ant could dynamically > configure itself to load the parallelizing implementation of the state > machine or the distributed implementation. > > So long as the design is flexible enough that the kinds of usecases that > Dominique and Gilles are suggesting can be implemented eventually, then the > KISS principle can still be followed. > > I would also note that features like DSLs for custom builds, automatic > parallelism, and distribution to a fault tolerant cluster are exactly the > kinds of features that would allow many users that I know of to justify > allocating resources to rewrite major build scripts. > > > On 2/18/2012 11:26 AM, Mansour Al Akeel wrote: >> >> Keeping it simple, is a great idea. >> I am not sure if introducing parallelism is a good idea or if it's >> easy to implement and maintain. >> >> If it is design is modular, I think all these can be added as plugins. >> Performance ??!! >> >> >> On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton >> wrote: >>> >>> This too I find a great idea. Multicores mean we need more ways of >>> exploiting parallelism, particularly if they can be identified >>> automatically >>> by the application. >>> >>> For backward compatibility it would have to be optional, though, either >>> specified on the command line or at the build file level or using a >>> different kind of target tag. Of course, the additional information you >>> suggest on targets would make that the case anyway, but in some cases I >>> think we might be able to automate it based just on what we have if the >>> build system is written properly so that dependencies on targets that >>> provide needed resources are explicitly identif
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Of course you are right, and initially parallelism and distributed builds will probably not be in the initial alpha release (unless it is on someones scratching list). Just getting something to run existing build files reliably will be fine. But you have suggested that we tag build files that require Ant 2 features with something that identifies them as requiring Ant 2. I think this is reasonable for the leap from Ant 1 to Ant 2, but one thing HTML has shown is that version numbers are an anti-pattern, which is why the DOCTYPE for HTML5 has done away with them (although that introduced its own "version" ie. no version). What is important is the list of features that are needed to interpret and run the file correctly. One can imagine a version tag listing Ant 2 as a minimum for a build file with an attribute for a comma separated list of the features that are required from Ant for the build. With this and the kind of packaging system that OSGI and possibly Java 8 will introduce, Ant could dynamically configure itself to load the parallelizing implementation of the state machine or the distributed implementation. So long as the design is flexible enough that the kinds of usecases that Dominique and Gilles are suggesting can be implemented eventually, then the KISS principle can still be followed. I would also note that features like DSLs for custom builds, automatic parallelism, and distribution to a fault tolerant cluster are exactly the kinds of features that would allow many users that I know of to justify allocating resources to rewrite major build scripts. On 2/18/2012 11:26 AM, Mansour Al Akeel wrote: Keeping it simple, is a great idea. I am not sure if introducing parallelism is a good idea or if it's easy to implement and maintain. If it is design is modular, I think all these can be added as plugins. Performance ??!! On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton wrote: This too I find a great idea. Multicores mean we need more ways of exploiting parallelism, particularly if they can be identified automatically by the application. For backward compatibility it would have to be optional, though, either specified on the command line or at the build file level or using a different kind of target tag. Of course, the additional information you suggest on targets would make that the case anyway, but in some cases I think we might be able to automate it based just on what we have if the build system is written properly so that dependencies on targets that provide needed resources are explicitly identified. Too many build systems in my experience rely on the order the dependencies are resolved on a higher order target rather than explicitly identifying dependencies on the targets that they are required on. This despite the fact that we have some language somewhere that you can't rely on the order of resolution of the dependencies. Sometimes that has proved a requirement to avoid targets that depended on each other, but I've seen it used as a shortcut instead far too often. Creating Ant clusters is also a great idea, at least to plan for. Perhaps something like Zookeeper to coordinate builds and a message bus like ActiveMQ or perhaps better QPid to schedule and report back to other nodes on the results. The idea of turning the dependency tree into a state machine is also interesting. It would combine the tree and the resolving of the tree with execution of tasks into a single entity. I worry, though, that some flexibility in our current system might be lost if the two portions are combined into one. Perhaps not. It could also introduce the possibility of cycles. Currently the dependency tree gets executed as a DAG but there have been a lot of requests for looping which a state machine could more easily support. On 2/18/2012 2:02 AM, Gilles Scokart wrote: For me, one feature for a 2,0 would be a different style of dependency tree that would allow better parallel execution (on the same machine, or why not on distributed machines). I see the 'targets' being more declarative, becoming a state transition saying : I need this resources in that state, I will use this other resources (and I don't want the to change during my execution, and I will produce this other resources in that other state. The dependency tree would be an logical engine finding the shortest path to go to the desired state, using parallel/distributed processing when possible. That's what I miss with existing build system : I want to go as quickly as possible to a desired build state (from a current state). Gilles Scokart On 17 February 2012 20:07, Bruce Athertonwrote: It doesn't require a rewrite, but a rewrite could simplify integrating a usecase like this as well as integrating other features that we already have into it and making them simpler and unified inthe code. I agree the usecase is an excellent one which could simplify the lives of exactly the type of users I am talking about. It
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Keeping it simple, is a great idea. I am not sure if introducing parallelism is a good idea or if it's easy to implement and maintain. If it is design is modular, I think all these can be added as plugins. Performance ??!! On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton wrote: > This too I find a great idea. Multicores mean we need more ways of > exploiting parallelism, particularly if they can be identified automatically > by the application. > > For backward compatibility it would have to be optional, though, either > specified on the command line or at the build file level or using a > different kind of target tag. Of course, the additional information you > suggest on targets would make that the case anyway, but in some cases I > think we might be able to automate it based just on what we have if the > build system is written properly so that dependencies on targets that > provide needed resources are explicitly identified. > > Too many build systems in my experience rely on the order the dependencies > are resolved on a higher order target rather than explicitly identifying > dependencies on the targets that they are required on. This despite the fact > that we have some language somewhere that you can't rely on the order of > resolution of the dependencies. Sometimes that has proved a requirement to > avoid targets that depended on each other, but I've seen it used as a > shortcut instead far too often. > > Creating Ant clusters is also a great idea, at least to plan for. Perhaps > something like Zookeeper to coordinate builds and a message bus like > ActiveMQ or perhaps better QPid to schedule and report back to other nodes > on the results. > > The idea of turning the dependency tree into a state machine is also > interesting. It would combine the tree and the resolving of the tree with > execution of tasks into a single entity. I worry, though, that some > flexibility in our current system might be lost if the two portions are > combined into one. Perhaps not. It could also introduce the possibility of > cycles. Currently the dependency tree gets executed as a DAG but there have > been a lot of requests for looping which a state machine could more easily > support. > > On 2/18/2012 2:02 AM, Gilles Scokart wrote: >> >> For me, one feature for a 2,0 would be a different style of dependency >> tree that would allow better parallel execution (on the same machine, >> or why not on distributed machines). >> I see the 'targets' being more declarative, becoming a state >> transition saying : I need this resources in that state, I will use >> this other resources (and I don't want the to change during my >> execution, and I will produce this other resources in that other >> state. >> >> The dependency tree would be an logical engine finding the shortest >> path to go to the desired state, using parallel/distributed processing >> when possible. >> >> That's what I miss with existing build system : I want to go as >> quickly as possible to a desired build state (from a current state). >> >> >> >> Gilles Scokart >> >> >> >> On 17 February 2012 20:07, Bruce Atherton wrote: >>> >>> It doesn't require a rewrite, but a rewrite could simplify integrating a >>> usecase like this as well as integrating other features that we already >>> have >>> into it and making them simpler and unified inthe code. I agree the >>> usecase >>> is an excellent one which could simplify the lives of exactly the type of >>> users I am talking about. >>> >>> It sounds like you are suggesting that the dependency tree be extensible >>> and >>> modifiable, perhaps manipulable, within targets as well so long as that >>> part >>> of the tree hasn't run yet. In a sense that is what macros do because >>> they >>> allow you to swap in some static block of tasks to replace a single task. >>> There is also the feature from EasyAnt for changing target dependencies. >>> But >>> what I'm hearing is that you want more flexibility than that. >>> >>> Something to walk the existing dependency tree, perhaps, with conditional >>> behaviors to modify the metadata on existing element such as dependencies >>> and if/unless, replacing the element with another or a subtree (perhaps >>> itself dynamically walked and created), adding branches, perhaps deleting >>> elements or subtrees. Kind of like what we can do with a tree of files >>> and >>> directories already. Does that sound like what the design you'd like to >>> see >>> would have? >>> >>> And perhaps it could encompass providing both the macro and target >>> dependency changes to the tree as well, along with any other code we have >>> that alters the dependency tree. I'm not sure which of the various ways >>> to >>> call back into Ant do this. I'm sure there are other examples in the >>> codebase. >>> >>> I'm not familiar enough with this part of the code any more to know >>> whether >>> there is already a single elegant solution in Ant 1 that all the code >>> which >>> modifies the dependency tree
Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
This too I find a great idea. Multicores mean we need more ways of exploiting parallelism, particularly if they can be identified automatically by the application. For backward compatibility it would have to be optional, though, either specified on the command line or at the build file level or using a different kind of target tag. Of course, the additional information you suggest on targets would make that the case anyway, but in some cases I think we might be able to automate it based just on what we have if the build system is written properly so that dependencies on targets that provide needed resources are explicitly identified. Too many build systems in my experience rely on the order the dependencies are resolved on a higher order target rather than explicitly identifying dependencies on the targets that they are required on. This despite the fact that we have some language somewhere that you can't rely on the order of resolution of the dependencies. Sometimes that has proved a requirement to avoid targets that depended on each other, but I've seen it used as a shortcut instead far too often. Creating Ant clusters is also a great idea, at least to plan for. Perhaps something like Zookeeper to coordinate builds and a message bus like ActiveMQ or perhaps better QPid to schedule and report back to other nodes on the results. The idea of turning the dependency tree into a state machine is also interesting. It would combine the tree and the resolving of the tree with execution of tasks into a single entity. I worry, though, that some flexibility in our current system might be lost if the two portions are combined into one. Perhaps not. It could also introduce the possibility of cycles. Currently the dependency tree gets executed as a DAG but there have been a lot of requests for looping which a state machine could more easily support. On 2/18/2012 2:02 AM, Gilles Scokart wrote: For me, one feature for a 2,0 would be a different style of dependency tree that would allow better parallel execution (on the same machine, or why not on distributed machines). I see the 'targets' being more declarative, becoming a state transition saying : I need this resources in that state, I will use this other resources (and I don't want the to change during my execution, and I will produce this other resources in that other state. The dependency tree would be an logical engine finding the shortest path to go to the desired state, using parallel/distributed processing when possible. That's what I miss with existing build system : I want to go as quickly as possible to a desired build state (from a current state). Gilles Scokart On 17 February 2012 20:07, Bruce Atherton wrote: It doesn't require a rewrite, but a rewrite could simplify integrating a usecase like this as well as integrating other features that we already have into it and making them simpler and unified inthe code. I agree the usecase is an excellent one which could simplify the lives of exactly the type of users I am talking about. It sounds like you are suggesting that the dependency tree be extensible and modifiable, perhaps manipulable, within targets as well so long as that part of the tree hasn't run yet. In a sense that is what macros do because they allow you to swap in some static block of tasks to replace a single task. There is also the feature from EasyAnt for changing target dependencies. But what I'm hearing is that you want more flexibility than that. Something to walk the existing dependency tree, perhaps, with conditional behaviors to modify the metadata on existing element such as dependencies and if/unless, replacing the element with another or a subtree (perhaps itself dynamically walked and created), adding branches, perhaps deleting elements or subtrees. Kind of like what we can do with a tree of files and directories already. Does that sound like what the design you'd like to see would have? And perhaps it could encompass providing both the macro and target dependency changes to the tree as well, along with any other code we have that alters the dependency tree. I'm not sure which of the various ways to call back into Ant do this. I'm sure there are other examples in the codebase. I'm not familiar enough with this part of the code any more to know whether there is already a single elegant solution in Ant 1 that all the code which modifies the dependency tree shares, but given our BC requirements I doubt it. One example of a FileSystemProvider that Java 7 suggests in its API docs is a "memory" file system, one identified by the URL "memory://". Perhaps our dependency tree could be a kind of file system, then we could reuse vast swathes of code we already have, both in the standard class libraries and in Ant itself. Just an idea off the top of my head. On 2/17/2012 5:53 AM, Dominique Devienne wrote: 2012/2/17 Bruce Atherton: A lot of companies have their own, internally written build file
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
For me, one feature for a 2,0 would be a different style of dependency tree that would allow better parallel execution (on the same machine, or why not on distributed machines). I see the 'targets' being more declarative, becoming a state transition saying : I need this resources in that state, I will use this other resources (and I don't want the to change during my execution, and I will produce this other resources in that other state. The dependency tree would be an logical engine finding the shortest path to go to the desired state, using parallel/distributed processing when possible. That's what I miss with existing build system : I want to go as quickly as possible to a desired build state (from a current state). Gilles Scokart On 17 February 2012 20:07, Bruce Atherton wrote: > It doesn't require a rewrite, but a rewrite could simplify integrating a > usecase like this as well as integrating other features that we already have > into it and making them simpler and unified inthe code. I agree the usecase > is an excellent one which could simplify the lives of exactly the type of > users I am talking about. > > It sounds like you are suggesting that the dependency tree be extensible and > modifiable, perhaps manipulable, within targets as well so long as that part > of the tree hasn't run yet. In a sense that is what macros do because they > allow you to swap in some static block of tasks to replace a single task. > There is also the feature from EasyAnt for changing target dependencies. But > what I'm hearing is that you want more flexibility than that. > > Something to walk the existing dependency tree, perhaps, with conditional > behaviors to modify the metadata on existing element such as dependencies > and if/unless, replacing the element with another or a subtree (perhaps > itself dynamically walked and created), adding branches, perhaps deleting > elements or subtrees. Kind of like what we can do with a tree of files and > directories already. Does that sound like what the design you'd like to see > would have? > > And perhaps it could encompass providing both the macro and target > dependency changes to the tree as well, along with any other code we have > that alters the dependency tree. I'm not sure which of the various ways to > call back into Ant do this. I'm sure there are other examples in the > codebase. > > I'm not familiar enough with this part of the code any more to know whether > there is already a single elegant solution in Ant 1 that all the code which > modifies the dependency tree shares, but given our BC requirements I doubt > it. > > One example of a FileSystemProvider that Java 7 suggests in its API docs is > a "memory" file system, one identified by the URL "memory://". Perhaps our > dependency tree could be a kind of file system, then we could reuse vast > swathes of code we already have, both in the standard class libraries and in > Ant itself. Just an idea off the top of my head. > > > On 2/17/2012 5:53 AM, Dominique Devienne wrote: >> >> 2012/2/17 Bruce Atherton: >>> >>> A lot of companies have their own, internally written build file >>> generators >>> just so their build systems are consistent and exactly what they want. >>> Our >>> Related Projects and External Tools page has some of these that were made >>> public, I suspect. >>> >>> Surely there is a better way than requiring users of Ant to write >>> generators >>> to deal with the complexity and keep it customized. >> >> At one point I did write a build(s) (XSLT-based) generator >> specifically for a large and hairy project. Later I rewrote the whole >> thing with macrodefs. But my point is that I don't view build >> generators as bad, in fact it often helps IMHO to have a declarative >> custom DSL (in XML in my case, so read "DSL" with a grain of salt) >> that's used as the input for generating Ant build fragments, and have >> those fragments be able to "insert" them into the target graph. I've >> also long felt Ant needed generalized if/unless/os (and my own >> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or >> UnknownElement if you prefer), just read the recent "add if/unless to >> 's" thread. is nice, but you can't use >> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All >> those things you can often do more easily with a generator, but that's >> often cumbersome, doesn't play well with IDEs, etc... I guess I'm >> saying I've often wished for generator-like features as a built-in >> part of Ant. Do you see what I'm saying? Ant now does late >> "conversion" from UnkownElement to actual configuration of the Java >> code it maps to, and a way to influence/transform that almost AST-like >> graph would make Ant more powerful and flexible, perhaps at the >> expense of creating "dialects" unreadable to someone not familiar with >> them. Given Ant's XML roots, perhaps a tighter built-in integration >> with XSLT to dynamically "rewrite" the build at runtime/buildtime >> wou
