ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: how to call macros dynamically?
Date Tue, 06 Jun 2006 14:55:35 GMT
>  <switch value="${project.type}">
>  <case value="jar">
>    <package-jar />
>  </case>
>  ..
>  <case value="ear">
>    <package-ear />
>  </case>
>  </switch>
> Having a  "run-macro" around I could shorten things to simply write
>  <run-macro name="package-${project.type}" />

Indeed, that's what I had in mind by hidden conditional.

That's one way to do it, but probably not one of the Ant ways.

For example, the above could be replaced by a single empty-target
depending on the 4 possible package-* targets, each with an
appropriate 'if' attribute. Or with a <antcall> (limited use of
<antcall> is usually not that expensive).

I so think you are working a bit "against the grain" with Ant here ;-)

> Another thing that strikes me is the distinction between a target and a
> task and macrodef.
> It's rather easy to implement a task executing an arbitrary target using
> getProject().executeTarget().

Sure, that's the safe <antcall> in Ant, or the less safe <runtarget>
in Ant-Contrib.

> Why not providing the same functionality for a macro as well? Honestly, I
> regard a target
> nothing more than a "public" macro, i.e. a macro able to call from the
> command line.

That's because you think of them in procedural term. When a target as
dependencies, it's not the same ball game. In theory, the dependencies
of a target should be only the pre-requisite of the target, and not an
ordered list of steps to fun before, and then the Ant engine would be
allowed to order the execution of theses target anyway it likes
(possibly parallelizing them) as long the the pre-requisites are met.
There's even an Executor proposal to behave that way.

Sure, it's not the way Ant works, or will ever work in all likelyhood,
but that's way I think it's wrong to think of targets as "public"

It's similar to how an XSLT engine processes it's templates. Most
processors are still mostly procedural right now, but the design
allows the engine to work in a non-procedural way (Read Dr. Kay's
excellent books for more details).

That said, feel free to implement a <macrocall> or <runmacro> task ;-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message