Peter Donald wrote: > At 08:16 17/5/01 -0700, you wrote: > >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?
> > What you describe - while useful is not something that ant alone is meant > to solve. Instead of having generic buildfiles I would recomend that > instead something like XSLT be used to build specific build files for each > product. However if your build.xml files change regularly this can be > painful and I don't know what would be best ;) > > Cheers, > > Pete > > *-----------------------------------------------------* > | "Faced with the choice between changing one's mind, | > | and proving that there is no need to do so - almost | > | everyone gets busy on the proof." | > | - John Kenneth Galbraith | > *-----------------------------------------------------* IMHO, Ant should solve this problem. This kind of thing I have seen many times. If it's not meant to solve this problem, what value does it have. I have reincluded the description of the problem below, since you snipped it without comment. Anybody else agree that ant should solve the problem described below with obscuring what's it is doing with build file generation with XSLT? 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. 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 tasks. 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.
