I am the original poster of this thread. I thought I would bring it back to the original discussion of if/unless for tasks. I have tried to explain below the motivation for modifying ant to handle if/unless per task. It seems to me that this would be a common problem and should be a sweet spot for ant. Any suggestions on how to do this without conditionals?
We have 31 different modules all maintained by CVS. We have several different products that can include any combination of the 31 CVS modules. We need a process that can build any of the products (i.e. any combination of modules) based on CVS tag. We also need a module level build process for each module that understands how to build just that particular module. We have also defined default targets that all build files (both product and module) must support. These are clean, fetch, compile, test, docs, package, and deploy. Given this we defined a two level system. At the highest level we have one build file that understands all possible modules. This is called the root build. The root build coordinates the build of each module based on the target called and CVS tag. For example, a root clean will call all clean targets for each module checked out. To understand weather or not a module's build targets can be called from the root build, I use a target that checks each module for a build file and set a property if it is available to be called with an ant task. After checking all modules build availability, I need to conditionally call the ant task for each module, thus the if/unless for tasks. Without if/unless for tasks and using the most frequently offered alternative, I would need to wrap all 31 ant calls in a target. Plus each module supports 6 default targets. So now I have 186 (31 x 6) wrapped tasks in their own target, all just to get conditional processing of an ant task. I am sure this is not what is meant by a target. With this system, the root build is generic enough to build any CVS tag with any combination of modules. And we like what we have. It is very clear from the build file what is intended. BTW, we also have a two tiered system of property files (root and module), I implemented an override attribute for property so the modules could override configuration properties from the root properties file e(i.e. mutable properties). But I'll save that one for another day:) -alan
