> From: Gus Heck [mailto:[EMAIL PROTECTED]
>
> I'm not sure I buy your 3 things argument. In my mind there
> are 2 things
> in what is previously proposed...
>
> properties and parameters
>
The question is when expantions happen. We are here in the MACRO
world, and in that world there are ussually those three things.
> Templates appear to be something new, though I don't think I
> like them
> (see below)
>
> > (1) --> ${xyz}
> > (2) --> ${macroattr:xyz}
> > (3) --> ${macrotemplate:xyz}
> >
Well, as I said I use those terms above just as examples, I am not
hookup in words,
I was just looking for some identifier to describe them. Still the
concepts
I am expressing are very clasical ones, these are not things out of the
blue.
> >So for a definition like:
> >
> > <property name="xyz" value="true"/>
> >
> Now ${xyz}" is true forevermore because properties are immutable
>
> > <macrodef name="abc">
> > <attribute name="pqr"/>
> > <sequential>
> > <javac debug="${xyz}" ... />
> >
> This line ${xyz} should get replaced
>
> > <javac debug="${macroattr:pqr}" ... />
> > <javac debug="${macrotemplate:xyz}" ... />
> > </sequential>
> > </macrodef>
> >
> >
> I'm not sure how you get a second level of expansion, or if
> it is desireable
>
> >After this definition the macro that is actually expanded will look
> >something like:
> >
> > <attribute name="pqr"/>
> > <sequential>
> > <javac debug="true" ... />
> > <javac debug="${macroattr:pqr}" ... />
> > <javac debug="${xyz}" ... />
> > </sequential>
> >
> >which will be further expanded in a call frangment, maybe inside an
> ><ant> call:
> >
> > <property name="xyz" value="false"/>
> > <abc pqr="true"/>
> > <abc pqr="false"/>
> >
> I'm not sure this makes sense (to me at least).... if it is
> part of an
> ant call, then the macrodef should be in the build file used in the
> antfile atribute... in which case your first javac might
> also come out
> with debug=false (assuming inheritall=false, and the property
> definition
> was before the macro definition) or debug="${xyz}" (unexpanded, and
> causing the build to fail because it wasn't defined yet, if
> the property
> isn't before the macro definition, as you have shown). If the
> task does
> property replacement at invocation time, then you still
> should get debug="false" for your first javac since the
> property won't have been
> expanded yet.
>
Even when using <antcall/> the call may not redefine the macro
nor any other <taskdef/> in the buildfile. This may happen if the
definitions
are inside a target which is not evaluated as part of the antcall
target.
So it is completely possible to have the situation above. Furthermore,
the <antcall/> can be as follows:
<antcall target="subcall">
<param name="xyz" value="false"/>
</antcall>
> If macro definitions are available to sub builds, then your 3rd case
> might occur, but I don't think it would be good to allow macros to be
> called across build file boundaries. builds would be almost
> unintelligible without tracking down the macros from other files.
>
This is all regular kosher ANT stuff, up to this day, <taskdef/>s get
inherited, they do not need to be redeclared for the task to be
available
during the <antcall/>. Are you proposing that we have a different,
special case,
semantics for <macrodef>?
> It would also bring up yet another scoping issue for 2 files that
> defined macros with the same name and then one called the
> other. Granted
> this might be an xml namespaces thing, but the more parts of ant that
> require namespaces the steeper the learning curve for new users.
>
We already have a solution for the case of <taskdef> I would just like
the behavior on both cases to be the same, so to reduce the leaarning
curve.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
