>> 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).
Sure you agree that "run-macro" is by far more elegant than working with
such a target?
Also, I do not need to care about this hidden conditional if I'm going to
extend the list
of known project types.
>> Or with a <antcall> (limited use of <antcall> is usually not that
>> expensive).
Hmm, I thought that there's no need for antcall any longer - now as
we have macros.
>> That's because you think of them in procedural term.
Still I can't see the general problem treating a target like a
special kind of macro .. (target = public macro + dependencies).
>> That said, feel free to implement a <macrocall> or <runmacro>
>> task ;-)
I'm stuck in NullPointerExceptions :-)
"Dominique Devienne" <[EMAIL PROTECTED]>
06-06-2006 16:55
Please respond to
"Ant Developers List" <dev@ant.apache.org>
To
"Ant Developers List" <dev@ant.apache.org>
cc
Subject
Re: how to call macros dynamically?
> <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"
macros.
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 ;-)
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
