ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan George <al...@hereuare.com>
Subject Re: if and unless attributes for all Tasks
Date Fri, 18 May 2001 17:07:19 GMT
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.



Mime
View raw message