ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags
Date Wed, 07 Jan 2004 17:13:37 GMT
Actually the new <for> task uses a <macrodef> type
approach to avoid the <antcall>.

-Matt

--- Dominique Devienne <DDevienne@lgc.com> wrote:
> > From: Jose Alberto Fernandez
> [mailto:jalberto@cellectivity.com]
> > 
> > > From: Dominique Devienne
> [mailto:DDevienne@lgc.com]
> > >
> > > For maybe a little use case, we have different
> types of
> > > tests, UNIT tests, GUI tests, DB tests, etc...
> each in its own target.
> > >
> > > The test target calls them all, by explicitly
> listing all the
> > > test types. I'd happily write depends="test-*"
> insteall of
> > > depends="test-UNIT, test-GUI, test-DB, ...".
> > >
> > 
> > Hummm, this looks like a foreach to me. Or more
> exactly
> > using the new <for/> task of antcontrib (which I
> think it should be
> > candidate to the 3rd party task of the year
> award).
> > "Find all the target names into a property and
> then use for to execute
> > the antcalls:
> > 
> >    <for param="target" list="${test.targets}>
> > 	<sequential>
> >          <antcall target="@{target}"/>
> >       </sequential>
> >    </for>
> 
> Hmmm, you have to pay the expense of an <antcall>,
> which is significant in speed but especially in
> memory,
> and then you must be careful of property/reference
> inheritance,
> and bypass the static target analysis.
> 
> > I use a script to look at target names and get
> those of my interest.
> 
> Thus you need a scripting language and bsf and write
> a script to
> look up target names... I'm not that fond of such a
> solution.
> 
> > In other words, it seems all you may want to do
> can be done with
> > the available tasks.
> 
> Without going to Perl-extremes, sometimes having
> multiple ways to
> do something is a good thing, especially when one
> way is in the fact
> very convoluted, requires lots of external
> tasks/code, and the
> other way is cleaner, faster, uses less memory, and
> is built-in
> without any external dependencies.
> 
> Which is why I still favor this enhancement. --DD
> 
> > > Anyways, maybe the patch writer would have a
> better use case ;-)
> > 
> > Yeap.
> > 
> > Jose Alberto
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message