on 7/24/00 7:21 PM, Jose Alberto Fernandez at [EMAIL PROTECTED] wrote: > I think that the design of ANT was that of a declerative tool.
Speaking as the original author: Yes, it was... The idea is "here's a list of targets, I want to execute that one (and by the way respect the dependancy ordering)". And each target is simply a list of tasks. Nothing more was intended. Now, it's come a long way with the ability to script and other things, but.... > I do not know if you can make all the parties to agree into changing > the idea of ANT to become a procedural tool. Procedural things go into the task code, or into scripts (which I did fight for a while, but Sam *was* persuasive in his arguments, as well as being correct that if you had to break away to logic, doing it in a script was a good thing). The concept of a <foreach> task really really really makes me queasy. > I would agree with you on the need to have some way to encapsulate the > scope of namedvalues (properties, variables or whatever other name). > In particular, I am not sure with the idea of subprojects not being allowed > to define their own local variables. This means that is is not possible > to have two originally unrelated projects and then make one call the other > because the property names may clash. That seems like wrong. That does seem wrong. My posts about scoping properties to project were stated in the single project setting, but apply almost equally to the tree'd project setting. When a target's task starts another ant build, with a subproject, that subproject should be "autonomous" in almost every respect (except the ability for the parent to set props in the subproject). .duncan
