Import in Antlibs (Re: [new tasks] presetdef and macrodef)
Gus Heck wrote, On 25/08/2003 18.02: Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... 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, s get inherited, they do not need to be redeclared for the task to be available during the . ... We already have a solution for the case of I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? How does a macro defined in the build become an antlib? The easiest way is to make it possible for antlibs to contain buildfiles that are imported. Antlibs would thus be jars that contain tasks, typedefs, and buildfiles. When loaded, the taskdefs are called, the typedefs too, and the buildfile is imported. This is what we do in Centipede, and it works ATM quite well, as we are able to thus to create antlibs easily even without any java code, only by including a buildfile. The alternative would be to allow only special buildfile snippets that contain macrodefs, that is to check that there are only macrodefs and import that file. What do others think? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Nicola Ken Barozzi wrote: [returned from holiday, happy to read the list again :-) ] Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... 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, s get inherited, they do not need to be redeclared for the task to be available during the . ... We already have a solution for the case of I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? How does a macro defined in the build become an antlib? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
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.
I would personally prefer a slightly more distinct syntax that didn't
use ${} for things that arn't exactly properties. Looking at it another
way: your suggestion is a half-magic property :) It reserves property
names starting with macroattr: and macrotemplate: as special, and
different from other properites.
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, s get
inherited, they do not need to be redeclared for the task to be
available
during the . Are you proposing that we have a different,
special case,
semantics for ?
I hadn't realized that taskdefs did this, but if it were up to me I
wouldn't have designed it this way. I would prefer to see the taskdefs
in each build file, so that I don't have to find out who's calling the
buildfile to find out where to find out what the task does. Any time you
get that many find-outs in a sentance it is clearly a royal pain in the
making (imho). :).
In otherwords, I would have prefered the simple rule, "if it isn't part
of the standard distro of ant, there will be a taskdef in the build to
tell you what it is." I don't think saving a few extra lines of typing
(or cut/paste) for the taskdefs is really worth making the build
unreadable without reference to another build (which won't be known
unless it appears in a comment).
I havn't followed the antlib topic closely enough (I havn't followed it
at all really because of the sheer volume of mail on those threads, and
the need to get some of my own work done :) ), but I get the impression
that antlib might reasonably eliminate the taskdef stuff by creating a
single place to look for definitions of things that arn't part of the
standard distro. and that would be fine. I only object to having to
having the builds depend on things defined in other builds with no
pointer to the definition (or standard location for the definition).
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
[returned from holiday, happy to read the list again :-) ] Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... 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, s get inherited, they do not need to be redeclared for the task to be available during the . ... We already have a solution for the case of I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
> 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:
> >
> >
> >
> Now ${xyz}" is true forevermore because properties are immutable
>
> >
> >
> >
> >
> >
> This line ${xyz} should get replaced
>
> >
> >
> >
> >
> >
> >
> 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >which will be further expanded in a call frangment, maybe inside an
> > call:
> >
> >
> >
> >
> >
> 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 the call may not redefine the macro
nor any other 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 can be as follows:
> 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, s get
inherited, they do not need to be redeclared for the task to be
available
during the . Are you proposing that we have a different,
special case,
semantics for ?
> 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 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]
Re: [new tasks] presetdef and macrodef
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
Templates appear to be something new, though I don't think I like them
(see below)
(1) --> ${xyz}
(2) --> ${macroattr:xyz}
(3) --> ${macrotemplate:xyz}
So for a definition like:
Now ${xyz}" is true forevermore because properties are immutable
This line ${xyz} should get replaced
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:
which will be further expanded in a call frangment, maybe inside an
call:
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.
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.
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.
To effectively finish executing the following ANT fragment:
So, as long as we can acomplish something like this, and we do not add a
bunch
of new machinery in the process, I think it is a wonderful feature.
Jose Alberto
-
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]
RE: [new tasks] presetdef and macrodef
> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2003 5:56 AM
> To: Ant Developers List
> Subject: RE: [new tasks] presetdef and macrodef
>
> I have no big issue on which syntax is used on each case, but I just
> would like to point out that there are actually 3 types of properties that
> need to be taken into consideration:
>
> 1) Properties to be expanded when the definition of the macro is found
> This is what Dominique wants "${xyz}" to mean, and I was looking for
> a syntax to express it.
That's the way properties have worked, and it should stay that way!
> 2) Attribute properties which are parameters on the call of the macro
> This is what people want to have a different syntax for, to
> distinguish from the rest, it was proposed to use [EMAIL PROTECTED] or
> (@xyz).
Thus the single new syntax (@attr-name) for example.
> 3) Properties to be expanded at the time of the call from the
> environment in which the call is made, this is what "${xyz}"
> means right now. As a macro or template definition I need to
> have a way to refer to things in the context of the expansion,
> so we need syntax for it.
There is absolutely no need for this 'implicit' attribute!!!
If you want your macro to be parametrizeable on something,
define an additional attribute.
You can then use the regular ${name} syntax to populate that explicit
attribute value, which regular ${name} semantic.
> So as you can see there are three diferent things here, that need to be
> represented. I really do not like inventing three diferent notations,
> if it can be helped in particular given the fact that we already have
> a ton of machinery in ANT that has been defined and seem to never
> being reused.
Uhh? Unused machinery? Anyways...
These is not 3 different things. There regular property expansion as it has
always been, and there a new syntax for dealing with a new type of tasks (or
meta-tasks I should say) like , and if it ever makes it
to Ant.
I never said is bad, on the contrary. What I have been saying all
along, and will persist on saying, is that the meaning ${name} should *NOT*
be overloaded in any way, and the way to do this is to introduce a new
syntax for attributes/variables for tasks like and .
And I'll persist with my -1 on as long as it overloads the
meaning of ${name}. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
> From: Gus Heck [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >Dominique,
> >
> >As its name indicates is a MACRO. And macros are
> macros are
> >macros and they are suppose to be textually replaces at the point on
> >invocation.
> >
> >
> Of course the parameters need to be replaced. The point is they
> shouldn't look like properties. This way they can't be confused with
> properties. An alternate form to ${foo} is all that is needed. Just
> search for a diferent pattern... [EMAIL PROTECTED] or (@foo) or @{foo}
> or %{foo} or
> $[foo] or really anything that isn't ${foo}. Dominique did also point
> out that (@foo) and [EMAIL PROTECTED] are already commonly used in other
> contexts
> that build authors will be familliar with.
>
I have no big issue on which syntax is used on each case, but I just
would
like to point out that there are actually 3 types of properties that
need
to be taken into consideration:
1) Properties to be expanded when the definition of the macro is found
This is what Dominique wants "${xyz}" to mean, and I was looking for
a syntax to express it.
2) Attribute properties which are parameters on the call of the macro
This is what people want to have a different syntax for, to
distinguish
from the rest, it was proposed to use [EMAIL PROTECTED] or (@xyz).
3) Properties to be expanded at the time of the call from the
environment
in which the call is made, this is what "${xyz}" means right now. As
a
macro or template definition I need to have a way to refer to things
in
the context of the expansion, so we need syntax for it.
So as you can see there are three diferent things here, that need to be
represented.
I really do not like inventing three diferent notations, if it can be
helped
in particular given the fact that we already have a ton of machinery in
ANT
that has been defined and seem to never being reused. Looking at all
this
machinery, it seems to me we could use the PropertyHelpers (Handles?)
infrastructure
to diferentiate between the cases, as follows (just an idea):
(1) --> ${xyz}
(2) --> ${macroattr:xyz}
(3) --> ${macrotemplate:xyz}
So for a definition like:
After this definition the macro that is actually expanded will look
something like:
which will be further expanded in a call frangment, maybe inside an
call:
To effectively finish executing the following ANT fragment:
So, as long as we can acomplish something like this, and we do not add a
bunch
of new machinery in the process, I think it is a wonderful feature.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Different people understand different things under MACRO. But I'd say to
anybody who's familiar with Lisp, this is certainly has MACRO like
semantics. The difference would be that in Lisp you explicitly (using
"quote") have to tell the evalutor not to evaluate an expression in a macro
definition. E.g.
(defmacro Square (X) '(* ,X ,X))
which is equivalent to:
(defmacro Square (X) (quote (* ,X ,X)))
would have to desired effect. But as macros are expanded at compiler
pre-processor time the following definition would not work for the general
case:
(defmacro Square (X) (* ,X ,X))
For more on macros in Common Lisp take a look at these notes:
http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html.
--
knut
> Well, I must be stupid then... Unlike you, I don't consider a
> MACRO at all. It has nothing to do with *textual* replacement. The
> non-existent , and XML entity includes *are* textual replacement.
> certainly is NOT. is a TASK, which happens to define
> and the same time it implement a(nother) new TASK, using Ant's native XML
> syntax rather than Java code. It could as much be called , and
the
> feeble link to MACRO would then be even more tenuous that it already is!
>
> It turns out that when you write the implementation of that new task, you
> *ARE* using Ant's syntax to 'code' it, and thus Ant normal behavior of
> expanding properties *AS USUAL* should be respected.
>
> It's a huge leap to say the least to consider defining a
textual
> MACRO. I myself am very aware of Ant's introspection and property
expansion
> rules, which is why I *expect* them to be applied everywhere in Ant.
>
> So I repeat: I'm -1 to with non-standard expansion of Ant
> properties. This is non-bidding of course, as I am not a committer... --DD
>
> > -Original Message-
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 20, 2003 7:34 AM
> > To: Ant Developers List
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> > Dominique,
> >
> > As its name indicates is a MACRO. And macros are macros are
> > macros
> > and they are suppose to be textually replaces at the point on
> > invocation.
> > So the fact that properties are substituted at the expansion point is
> > what anyone understanding that it is a MACRO would expect.
> >
> > My point with allowing for a way to expand inline, (which I am not even
> > sure
> > gives any advantage, since properties are inmutable) is trying to
> > address
> > the fact that in many MACRO languages there is some way to evaluate some
> > things
> > at definition time and fix the value then. some sort of eval.
> >
> > Maybe one can acomplish this with some sort of property interceptor: So
> > a syntax like:
> >
> > ${macroinline:x} will cause the property "x" to be substituted
> > at definition time
> > while ${x} will get substituted at expansion time.
> >
> >
> > > -Original Message-
> > > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> > > Sent: 19 August 2003 21:24
> > > To: 'Ant Developers List'
> > > Subject: RE: [new tasks] presetdef and macrodef
> > >
> > >
> > > > -Original Message-
> > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, August 19, 2003 12:47 PM
> > > > To: Ant Developers List
> > > > Subject: RE: [new tasks] presetdef and macrodef
> > > >
> > > > > What I am saying is that even with a different notation for
> > > > > attributes, normal property resolution will take place in the
> > > > > context of the user of the macro, and not when the macro
> > > is defined.
> > > > > This is a consequence of the way is implemented, in
> > > > > particualar to support embedded elements.
> > > > >
> > > >
> > > > Now that you explained this, I would really like to have a way of
> > > > defining properties that are expanded at definition time. I do not
> > > > know if it can be done with the syntax we already have or we need
> > > > something diferent. Probably we do, since we would need a way to
> > > > distinguish between inlined (replace during definition) and not
> > > > inlined (replaced during evaluation) properties.
> > >
> > > I stopped arguing this point, as I was the only one concerned
> > > apparently, but since Jose Alberto brings it up again...
> > >
> > > Having ${NAME} not ev
Re: [new tasks] presetdef and macrodef
Jose Alberto Fernandez wrote:
Dominique,
As its name indicates is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
Of course the parameters need to be replaced. The point is they
shouldn't look like properties. This way they can't be confused with
properties. An alternate form to ${foo} is all that is needed. Just
search for a diferent pattern... [EMAIL PROTECTED] or (@foo) or @{foo} or %{foo} or
$[foo] or really anything that isn't ${foo}. Dominique did also point
out that (@foo) and [EMAIL PROTECTED] are already commonly used in other contexts
that build authors will be familliar with.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
I stopped arguing this point, as I was the only one concerned apparently,
but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME property, at
the time the task it's used in ( is this case) is executed, is
REALLY REALLY BAD in my sincere opinion. Maybe does it, but that
I agree with you on this... I had to use foreach for the first time
recently and was astounded that it had been written that way. It
completely confuses the issue of property immutability, and makes the
parameter hard to find. You need to know what the argument is before you
look for it. Think about explaining property imutability to someone...
${foo.bar} can never change... exept when it isn't a property... "how do
I know it isn't a property?" they ask... The answer would be you just
have to know the tasks where ${foo.bar} might not be a property, and
check what the parameter name is. At that point the person you are
explaining this to rolls their eyes and says "Ugh. That is annoying" :)
I think macrodef should not duplicate this problem and if foreach ever
came into ant it should have a namechange and new parameter system.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Well, I must be stupid then... Unlike you, I don't consider a
MACRO at all. It has nothing to do with *textual* replacement. The
non-existent , and XML entity includes *are* textual replacement.
certainly is NOT. is a TASK, which happens to define
and the same time it implement a(nother) new TASK, using Ant's native XML
syntax rather than Java code. It could as much be called , and the
feeble link to MACRO would then be even more tenuous that it already is!
It turns out that when you write the implementation of that new task, you
*ARE* using Ant's syntax to 'code' it, and thus Ant normal behavior of
expanding properties *AS USUAL* should be respected.
It's a huge leap to say the least to consider defining a textual
MACRO. I myself am very aware of Ant's introspection and property expansion
rules, which is why I *expect* them to be applied everywhere in Ant.
So I repeat: I'm -1 to with non-standard expansion of Ant
properties. This is non-bidding of course, as I am not a committer... --DD
> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 20, 2003 7:34 AM
> To: Ant Developers List
> Subject: RE: [new tasks] presetdef and macrodef
>
> Dominique,
>
> As its name indicates is a MACRO. And macros are macros are
> macros
> and they are suppose to be textually replaces at the point on
> invocation.
> So the fact that properties are substituted at the expansion point is
> what anyone understanding that it is a MACRO would expect.
>
> My point with allowing for a way to expand inline, (which I am not even
> sure
> gives any advantage, since properties are inmutable) is trying to
> address
> the fact that in many MACRO languages there is some way to evaluate some
> things
> at definition time and fix the value then. some sort of eval.
>
> Maybe one can acomplish this with some sort of property interceptor: So
> a syntax like:
>
> ${macroinline:x} will cause the property "x" to be substituted
> at definition time
> while ${x} will get substituted at expansion time.
>
>
> > -Original Message-----
> > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> > Sent: 19 August 2003 21:24
> > To: 'Ant Developers List'
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> >
> > > -----Original Message-
> > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 19, 2003 12:47 PM
> > > To: Ant Developers List
> > > Subject: RE: [new tasks] presetdef and macrodef
> > >
> > > > What I am saying is that even with a different notation for
> > > > attributes, normal property resolution will take place in the
> > > > context of the user of the macro, and not when the macro
> > is defined.
> > > > This is a consequence of the way is implemented, in
> > > > particualar to support embedded elements.
> > > >
> > >
> > > Now that you explained this, I would really like to have a way of
> > > defining properties that are expanded at definition time. I do not
> > > know if it can be done with the syntax we already have or we need
> > > something diferent. Probably we do, since we would need a way to
> > > distinguish between inlined (replace during definition) and not
> > > inlined (replaced during evaluation) properties.
> >
> > I stopped arguing this point, as I was the only one concerned
> > apparently, but since Jose Alberto brings it up again...
> >
> > Having ${NAME} not evaluate to the value, if any, of the NAME
> > property, at the time the task it's used in ( is
> > this case) is executed, is REALLY REALLY BAD in my sincere
> > opinion. Maybe does it, but that doesn't make it
> > any better. Properties should *always* be evaluated at the
> > place where they are defined.
> >
> > If I'm not mistaken, and ${NAME} is evaluated as the time the
> > defined Macro is used, rather than defined, then is becomes
> > some kind of implicit attribute of that Macro, and it's much
> > better to explicitly define it as an attribute.
> >
> > OTOH, if it behaves 'normally', as in what Ant does today, it
> > is simply a way to customize the way the macro itself (its
> > implementation if you will).
> >
> > It seems that so far, my point has either not been well
> > understood, or dismissed (which is troubling to me, given the
> > huge confusion that would result IMHO). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Dominique,
As its name indicates is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
So the fact that properties are substituted at the expansion point is
what anyone understanding that it is a MACRO would expect.
My point with allowing for a way to expand inline, (which I am not even
sure
gives any advantage, since properties are inmutable) is trying to
address
the fact that in many MACRO languages there is some way to evaluate some
things
at definition time and fix the value then. some sort of eval.
Maybe one can acomplish this with some sort of property interceptor: So
a syntax like:
${macroinline:x} will cause the property "x" to be substituted
at definition time
while ${x} will get substituted at expansion time.
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: 19 August 2003 21:24
> To: 'Ant Developers List'
> Subject: RE: [new tasks] presetdef and macrodef
>
>
> > -Original Message-
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 19, 2003 12:47 PM
> > To: Ant Developers List
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> > > What I am saying is that even with a different notation for
> > > attributes, normal property resolution will take place in the
> > > context of the user of the macro, and not when the macro
> is defined.
> > > This is a consequence of the way is implemented, in
> > > particualar to support embedded elements.
> > >
> >
> > Now that you explained this, I would really like to have a way of
> > defining properties that are expanded at definition time. I do not
> > know if it can be done with the syntax we already have or we need
> > something diferent. Probably we do, since we would need a way to
> > distinguish between inlined (replace during definition) and not
> > inlined (replaced during evaluation) properties.
>
> I stopped arguing this point, as I was the only one concerned
> apparently, but since Jose Alberto brings it up again...
>
> Having ${NAME} not evaluate to the value, if any, of the NAME
> property, at the time the task it's used in ( is
> this case) is executed, is REALLY REALLY BAD in my sincere
> opinion. Maybe does it, but that doesn't make it
> any better. Properties should *always* be evaluated at the
> place where they are defined.
>
> If I'm not mistaken, and ${NAME} is evaluated as the time the
> defined Macro is used, rather than defined, then is becomes
> some kind of implicit attribute of that Macro, and it's much
> better to explicitly define it as an attribute.
>
> OTOH, if it behaves 'normally', as in what Ant does today, it
> is simply a way to customize the way the macro itself (its
> implementation if you will).
>
> It seems that so far, my point has either not been well
> understood, or dismissed (which is troubling to me, given the
> huge confusion that would result IMHO). --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]
RE: [new tasks] presetdef and macrodef
> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 19, 2003 12:47 PM
> To: Ant Developers List
> Subject: RE: [new tasks] presetdef and macrodef
>
> > What I am saying is that even with a different notation for
> > attributes, normal property resolution will take place in the
> > context of the user of the macro, and not when the macro is
> > defined. This is a consequence of the way is
> > implemented, in particualar to support embedded elements.
> >
>
> Now that you explained this, I would really like to have a way
> of defining properties that are expanded at definition time.
> I do not know if it can be done with the syntax we already have
> or we need something diferent. Probably we do, since we would need
> a way to distinguish between inlined (replace during definition)
> and not inlined (replaced during evaluation) properties.
I stopped arguing this point, as I was the only one concerned apparently,
but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME property, at
the time the task it's used in ( is this case) is executed, is
REALLY REALLY BAD in my sincere opinion. Maybe does it, but that
doesn't make it any better. Properties should *always* be evaluated at the
place where they are defined.
If I'm not mistaken, and ${NAME} is evaluated as the time the defined Macro
is used, rather than defined, then is becomes some kind of implicit
attribute of that Macro, and it's much better to explicitly define it as an
attribute.
OTOH, if it behaves 'normally', as in what Ant does today, it is simply a
way to customize the way the macro itself (its implementation if you will).
It seems that so far, my point has either not been well understood, or
dismissed (which is troubling to me, given the huge confusion that would
result IMHO). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> On Thursday 14 August 2003 17:44, Dominique Devienne wrote:
> > > -Original Message-
> > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > >
> >
> > >
> > > All of the expansions happen later on. If the macro is used in a
> > > different project to the project it is defined in, the
> properties in
> > > use will be of the project that the macro is used in*.
> >
> > Which is exactly why I don't like using the same syntax,
> which until
> > now
> > *always* expanded as if at the place of definition/use!!!
>
> What I am saying is that even with a different notation for
> attributes, normal property resolution will take place in the
> context of the user of the macro, and not when the macro is
> defined. This is a consequence of the way is
> implemented, in particualar to support embedded elements.
>
Now that you explained this, I would really like to have a way
of defining properties that are expanded at definition time.
I do not know if it can be done with the syntax we already have
or we need something diferent. Probably we do, since we would need
a way to distinguish between inlined (replace during definition)
and not inlined (replaced during evaluation) properties.
> >
> > > However, I can see
> > > that there can be issues with using the same notation for
> the macro
> > > expansion of attributes and then normal expansion of properties.
> >
> > So we're you planning on refusing 'normal' property expansion in
> > ? If two different syntax are used, it's obvious what's
> > what.
> >
> > > I am loath however to adding new rules for indicating variables.
> > > However if ant people want a different encoded for the macro
> > > variables, I would have no objection.
> >
> > OK, let's see:
> > 1) Introduce a new syntax (@name) for a new feature,
> >thus keeping the existing syntax ${name} its only behavior
> > 2) Overloading the existing ${name} syntax to behave differently
> >in
> >
> > It's a no brainer to me. I clearly vote for (1).
>
> As a temporary measure I have added a new attribute
> "attributestyle" to allow the notatation to be specified. The
> attribute can be "ant" (default) or "xpath". This should
> allow people to experiment with either formats, and we could
> choose one later.
>
I think this is the worst thing to do. Having flavors of the task will
only
cause confusion I am afraid. We should hash out our differences and
stick to one syntax.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Fri, 15 Aug 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > Or maybe s could even be inherited when using or > ? My understanding is that defines a new task, so it is inherited with <*ant*>subbuilds. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
> >
> > One thing you could do here is redefine itself
> > by doing something like:
> >
> >
> >
> >
> >
> >
> > which would realize your desired effect. This could be done internally
> > by when for example no name attribute is given.
>
> This could also be done by:
>
>
>
>
>
I was hoping that would be possible.
> You will however get a warning that the previous definition
> of javac has been overridden.
>
> I am thinking of adding an override attribute to allow suppressing
> this warning.
>
Sounds reasonable.
So instead of using a whole lot of standard user properties to make sure
that all tasks across all buildfiles use the same attribute values (e.g.
${debug}) I can simply a presets.xml buildfile in every project.
Or maybe s could even be inherited when using or ?
> >
> > It would be interesting to know what would happen if I write:
> >
> > ...
> >
> > would it use the value given in or that given in the actual
> > task? If the later, it means that the values given in would
be
> > default values for the task, which sounds much better.
> > Maybe we could rename it . :-)
>
> In this case what will happen is that javac#setDebug() gets called twice.
> First with the default value and second with "true". The effect
> this has depends on the task/type in question. Some tasks set a flag
> when an attribute is set and do not allow it to be set again.
>
Maybe not quite what one would expect. But I suppose most tasks could be
rewritten to pick up the value when it's set the second time.
--
knut
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 18:50, Jose Alberto Fernandez wrote: > I think this is fantastic work. Thanks. > > One thing you could do here is redefine itself > by doing something like: > > > > > > > which would realize your desired effect. This could be done internally > by when for example no name attribute is given. This could also be done by: You will however get a warning that the previous definition of javac has been overridden. I am thinking of adding an override attribute to allow suppressing this warning. > > > Finally, , in term of functionality and not > > implementation, is > > just a subset of in my opinion, and doesn't > > deserve Task status. > > I disagree here, IIUC, 's templates must have ALL the > content and parameters of the tasks inside, while > only sites some sort of default values. > > It would be interesting to know what would happen if I write: > > ... > > would it use the value given in or that given in the actual > task? If the later, it means that the values given in would be > default values for the task, which sounds much better. > Maybe we could rename it . :-) In this case what will happen is that javac#setDebug() gets called twice. First with the default value and second with "true". The effect this has depends on the task/type in question. Some tasks set a flag when an attribute is set and do not allow it to be set again. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 17:44, Dominique Devienne wrote:
> > -Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 14, 2003 11:22 AM
> > To: Ant Developers List
> > Subject: Re: [new tasks] presetdef and macrodef
> >
> > It is not a sub-set of . But there is a lot of overlap of
> > functionality. In fact after I got embeded elements to work for
> > ,
> > I replaced most uses of with .
> >
> > I think however that there is a place for For example
> > if you look at the current code of TaskDef, all it consists of is
> > setting two properties. This can be expressed using as
> >
> >
> > > adaptto="org.apache.tools.ant.task.Task"/>
> >
> >
>
> OK, I clearly misunderstood ... But then, you can also write:
>
>
>
>
>
> and still do,
>
>classname="org.apache.tools.ant.taskdefs.conditions.Or"/>
No, you cannot do this.
In this case has defined no attributes for "conditiondef"
so the name and classname will be rejected.
One could do
But one would need to do similar things for the other attributes and nested
elements.
>
> Can't you? So what's exactly the difference between and
> ??? I still don't get it I'm afraid...
>
> > > A middle ground would be to have something like this, closer to your
> > > current design:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > So it yields no task rename, work for any valid tasks, and is more
> > > explicit.
> >
> > True but not easy to implement (I think, although.) and does
> > something different to .
>
> I thought it was the goal of , but I was wrong of course.
>
> > > >
> > > >
> > >
> > > I have much less problem with, but I concur with others that
> > > overloading the behavior of ${name} is not good. This will be confusing
> > > to me and other users that property expansion will not happen as usual
> > > at definition time, but later on.
> >
> > All of the expansions happen later on. If the macro is used in a
> > different project to the project it is defined in, the properties
> > in use will be of the project that the macro is used in*.
>
> Which is exactly why I don't like using the same syntax, which until now
> *always* expanded as if at the place of definition/use!!!
What I am saying is that even with a different notation for
attributes, normal property resolution will take place in the context
of the user of the macro, and not when the macro is defined. This
is a consequence of the way is implemented, in particualar
to support embedded elements.
>
> > However, I can see
> > that there can be issues with using the same notation for the macro
> > expansion of attributes and then normal expansion of properties.
>
> So we're you planning on refusing 'normal' property expansion in
> ? If two different syntax are used, it's obvious what's what.
>
> > I am loath however to adding new rules for indicating variables.
> > However if ant people want a different encoded for the macro variables,
> > I would have no objection.
>
> OK, let's see:
> 1) Introduce a new syntax (@name) for a new feature,
>thus keeping the existing syntax ${name} its only behavior
> 2) Overloading the existing ${name} syntax to behave differently
>in
>
> It's a no brainer to me. I clearly vote for (1).
As a temporary measure I have added a new attribute "attributestyle" to
allow the notatation to be specified. The attribute can be "ant" (default)
or "xpath". This should allow people to experiment with either
formats, and we could choose one later.
>
> > > Another advantage of the second form is that one would not need to
> > > pre-declare the macro params (making it scripting-language-like), but
> > > on the other hand, pre-declaring makes it more explicitly when reading
> > > the macro what parameters it takes. If we force pre-declaration, we can
> > > then fail on dereference to non-declared macro-param.
> >
> > Yes, The current code does these checks.
>
> So how do you distinguish between regular properties dereference and
> attribute dereference again?
The checks (i.e. are the attributes/elements present) are done when the
macro is used.
>
> > > Should param be renamed attribute? , from the build writer
> > > point of view, creates a n
Re: [new tasks] presetdef and macrodef
Dominique Devienne wrote, On 14/08/2003 20.16: Jose Alberto answered that one indirectly. I know understand that the I had does not declare a 'name' or 'classname' attribute, and thus could not be used as I wrote it, whereas keeps access to all attributes of the preset'd type. Sorry for being so slow ;-) --DD While the tasks themselves are wonderful, it's possible that the current naming can confuse users, and DD is quite a knowledgebale (how the heck do you write it!?) one. I'm not a naming wizard (usually quite the opposite), but how about: becomes or or And -> or -> BTW, any name is fine for me as long as it's put in Ant 1.6 ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Jose Alberto answered that one indirectly. I know understand that the I had does not declare a 'name' or 'classname' attribute, and thus could not be used as I wrote it, whereas keeps access to all attributes of the preset'd type. Sorry for being so slow ;-) --DD > -Original Message- > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2003 11:44 AM > To: 'Ant Developers List' > Subject: RE: [new tasks] presetdef and macrodef > > > -Original Message- > > From: peter reilly [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 14, 2003 11:22 AM > > To: Ant Developers List > > Subject: Re: [new tasks] presetdef and macrodef > > > > It is not a sub-set of . But there is a lot of overlap of > > functionality. In fact after I got embeded elements to work for > > , > > I replaced most uses of with . > > > > I think however that there is a place for For example > > if you look at the current code of TaskDef, all it consists of is > > setting two properties. This can be expressed using as > > > > > > > adaptto="org.apache.tools.ant.task.Task"/> > > > > > > When (if) roles are introducted, one implementation would be > > to add a "role" or "restrict" attribute to . > > > >> classname="org.apache.tools.ant.taskdefs.conditions.Or" > > restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/> > > > >> classname="org.apache.tools.ant.types.selectors.Or" > > restrict="org.apache.tools.ant.types.selectors.FileSelector"/> > > > > one could use as > > > > > > restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/> > > > > > > and define: > > >classname="org.apache.tools.ant.taskdefs.conditions.Or"/> > > OK, I clearly misunderstood ... But then, you can also write: > > > > > > and still do, > >classname="org.apache.tools.ant.taskdefs.conditions.Or"/> > > Can't you? So what's exactly the difference between and > ??? I still don't get it I'm afraid... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
I think this is fantastic work.
As per Dominique's reservations, here are some observations that may
make things easier.
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> >
> > (formally known as extendtype)
> > this defines a new task or type based on a current ant
> task or type,
> > with attributes or elements preset.
> >
> > example useage:
> >
> >
> >
> >
> >may now be used as a task in the same way as
> > but the attribute debug and deprecation will be preset.
>
> Also, this kind of static attribute-binding is useful indeed
> (I've actually
> asked for it a few times), but is hardly a definition, and
> it's bad that it
> forces you to rewrite the task name. I don't want to modify
> all my builds to
> use just to take advantage of that feature.
>
One thing you could do here is redefine itself
by doing something like:
which would realize your desired effect. This could be done internally
by when for example no name attribute is given.
> Finally, , in term of functionality and not
> implementation, is
> just a subset of in my opinion, and doesn't
> deserve Task status.
>
I disagree here, IIUC, 's templates must have ALL the
content and parameters of the tasks inside, while
only sites some sort of default values.
It would be interesting to know what would happen if I write:
...
would it use the value given in or that given in the actual task?
If the later, it means that the values given in would be
default values for the task, which sounds much better.
Maybe we could rename it . :-)
> Much more useful IMO was be the ability to bind (or preset)
> values using
> XPath expressions, to follow your example:
>
> //javac/@debug = ${debug}
> //javac/@deprecation = ${deprecation}
>
> To just do it for an instance of Javac inside a particular target, do
>
> //[EMAIL PROTECTED]'compile']/javac/@debug = true
>
This sounds like global file transformations, since you are applying
the xpath all over, seems like something for a ProjectHelper like to do.
> A middle ground would be to have something like this, closer
> to your current
> design:
>
>
>
>
>
>
>
> So it yields no task rename, work for any valid tasks, and is
> more explicit.
>
More in the middle is something like the notation I proposed above,
which allows the user to decide whether he wants diferent flavours
(different names) or just globally apply the change.
>
> >
> > this defines a new task in the same way as except it
> > uses a as a defintion of the task. The
> > task has nested elements - param and element to allow the
> > user to specify attributes and elements of the new task. These
> > get substituted into the when the new task is
> > run.
> >
> > example: (from a current project)
> >
> >
> >
> >
> >
> >
> >
> >
> > > outfile="${target.dir}/${target}">
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > target.dir="${build.bin.dir}">
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> I have much less problem with, but I concur with
> others that
> overloading the behavior of ${name} is not good. This will be
> confusing to
> me and other users that property expansion will not happen as usual at
> definition time, but later on. I think we need another syntax
> for the macro
> param/attributes, and keep the ${} working as usual.
>
I really do not see what is so confusing, but +0 about it. defines
a "local" property which is expanded at call time. I have always wanted
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 11:22 AM
> To: Ant Developers List
> Subject: Re: [new tasks] presetdef and macrodef
>
> It is not a sub-set of . But there is a lot of overlap of
> functionality. In fact after I got embeded elements to work for
> ,
> I replaced most uses of with .
>
> I think however that there is a place for For example
> if you look at the current code of TaskDef, all it consists of is
> setting two properties. This can be expressed using as
>
>
> adaptto="org.apache.tools.ant.task.Task"/>
>
>
> When (if) roles are introducted, one implementation would be
> to add a "role" or "restrict" attribute to .
>
>classname="org.apache.tools.ant.taskdefs.conditions.Or"
> restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
>
>classname="org.apache.tools.ant.types.selectors.Or"
> restrict="org.apache.tools.ant.types.selectors.FileSelector"/>
>
> one could use as
>
>restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
>
>
> and define:
> classname="org.apache.tools.ant.taskdefs.conditions.Or"/>
OK, I clearly misunderstood ... But then, you can also write:
and still do,
Can't you? So what's exactly the difference between and
??? I still don't get it I'm afraid...
> > A middle ground would be to have something like this, closer to your
> > current design:
> >
> >
> >
> >
> >
> >
> >
> > So it yields no task rename, work for any valid tasks, and is more
> > explicit.
>
> True but not easy to implement (I think, although.) and does
> something different to .
I thought it was the goal of , but I was wrong of course.
> > >
> > >
> >
> > I have much less problem with, but I concur with others that
> > overloading the behavior of ${name} is not good. This will be confusing
> > to me and other users that property expansion will not happen as usual
> > at definition time, but later on.
>
> All of the expansions happen later on. If the macro is used in a
> different project to the project it is defined in, the properties
> in use will be of the project that the macro is used in*.
Which is exactly why I don't like using the same syntax, which until now
*always* expanded as if at the place of definition/use!!!
> However, I can see
> that there can be issues with using the same notation for the macro
> expansion of attributes and then normal expansion of properties.
So we're you planning on refusing 'normal' property expansion in ?
If two different syntax are used, it's obvious what's what.
> I am loath however to adding new rules for indicating variables.
> However if ant people want a different encoded for the macro variables,
> I would have no objection.
OK, let's see:
1) Introduce a new syntax (@name) for a new feature,
thus keeping the existing syntax ${name} its only behavior
2) Overloading the existing ${name} syntax to behave differently
in
It's a no brainer to me. I clearly vote for (1).
> > Another advantage of the second form is that one would not need to
> > pre-declare the macro params (making it scripting-language-like), but on
> > the other hand, pre-declaring makes it more explicitly when reading the
> > macro what parameters it takes. If we force pre-declaration, we can then
> > fail on dereference to non-declared macro-param.
>
> Yes, The current code does these checks.
So how do you distinguish between regular properties dereference and
attribute dereference again?
> > Should param be renamed attribute? , from the build writer
> > point of view, creates a new tasks, and we always speak of attributes
> > and nested elements, not params and nesting elements.
>
> I picked param, as some other tasks use param (foreach*,
> antcall) for something similar.
No, it's not something similar IMHO! You are implicitly creating a new task
at runtime, whereas and are tasks that use parameters
during their runtime. It's two different things, and again the meaning
should not be overloaded.
Please consider using instead of , re-enforcing this idea
that create a new task, as the same time that (@name)
re-enforcement the fact that it's not a regular property dereference.
Thanks, --D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 15:23, Dominique Devienne wrote:
> After all the praises, I hope my post doesn't sound too negative.
No problem.
> I also
> think it's a great addition Peter, I just have a few reservations ;-)
>
> See below... --DD
>
> > -Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> >
> > (formally known as extendtype)
> > this defines a new task or type based on a current ant task or type,
> > with attributes or elements preset.
> >
> > example useage:
> >
> >
> >
> >
> >may now be used as a task in the same way as
> > but the attribute debug and deprecation will be preset.
>
> I'll start by neat picking ;-) What does is binding a given
> value to a task attribute. In the C++ world, the method to do that are call
> bind, which is IMHO better that preset.
also allows nested elements to be predefined - or bound.
> Also, this kind of static attribute-binding is useful indeed (I've actually
> asked for it a few times), but is hardly a definition, and it's bad that it
> forces you to rewrite the task name. I don't want to modify all my builds
> to use just to take advantage of that feature.
>
> Finally, , in term of functionality and not implementation, is
> just a subset of in my opinion, and doesn't deserve Task status.
It is not a sub-set of . But there is a lot of overlap of
functionality. In fact after I got embeded elements to work for ,
I replaced most uses of with .
I think however that there is a place for For example
if you look at the current code of TaskDef, all it consists of is
setting two properties. This can be expressed using as
When (if) roles are introducted, one implementation would be
to add a "role" or "restrict" attribute to .
one could use as
and define:
>
> Much more useful IMO was be the ability to bind (or preset) values using
> XPath expressions, to follow your example:
>
> //javac/@debug = ${debug}
> //javac/@deprecation = ${deprecation}
>
> To just do it for an instance of Javac inside a particular target, do
>
> //[EMAIL PROTECTED]'compile']/javac/@debug = true
>
> I've always been annoyed to having to explicitly declare a bunch of task
> attributes taking properties when sensible default values just to be able
> to maybe override them.
>
> So in conclusion, I'm +1 to the ability to bind values to task/type
> attributes, but without requiring task name changes, and possibly with
> requiring a task. I'm -0 to as it is.
>
> A middle ground would be to have something like this, closer to your
> current design:
>
>
>
>
>
>
>
> So it yields no task rename, work for any valid tasks, and is more
> explicit.
True but not easy to implement (I think, although.) and does
something different to .
> >
> >
>
> I have much less problem with, but I concur with others that
> overloading the behavior of ${name} is not good. This will be confusing to
> me and other users that property expansion will not happen as usual at
> definition time, but later on.
All of the expansions happen later on. If the macro is used in a different
project to the project it is defined in, the properties in use will be of
the project that the macro is used in*. However, I can see
that there can be issues with using the same notation for the macro
expansion of attributes and then normal expansion of properties.
I am loath however to adding new rules for indicating variables.
However if ant people want a different encoded for the macro variables,
I would have no objection.
* This is different to where the project of the definer
is used to evaluate the preset attributes and elements.
This is a reason I called the second task , one
should consider it a lump of xml to be placed in at the current
location with substitutions of attributes and elements.
> I think we need another syntax for the macro
> param/attributes, and keep the ${} working as usual.
>
> I propose to use either:
> * the XSL syntax (@name)
> * or a Javadoc-like syntax [EMAIL PROTECTED] name}
>
> Another advantage of the second form is that one would not need to
> pre-declare the macro params (making it scripting-language-like), but on
> the other hand, pre-declaring makes it more explicitly when reading the
> macro what parameters it takes. If we force pre-declaration, we can then
> fail on dereference to non-declared macro-param.
Yes, The current code does these checks.
>
> Should param be renamed attribute? , from the build writer point
> of view, creates a new tasks, and we always speak of attributes and nested
> elements, not params and nesting elements.
I picked param, as some other tasks use param (foreach*,
antcall) for something similar.
* Locally I have modified foreach to behave the same way as macrodef,
(i.e run a sequential task in the same project with the different values of
the list or path)
Cheers Peter.
--
RE: [new tasks] presetdef and macrodef
After all the praises, I hope my post doesn't sound too negative. I also
think it's a great addition Peter, I just have a few reservations ;-)
See below... --DD
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
>
> (formally known as extendtype)
> this defines a new task or type based on a current ant task or type,
> with attributes or elements preset.
>
> example useage:
>
>
>
>
>may now be used as a task in the same way as
> but the attribute debug and deprecation will be preset.
I'll start by neat picking ;-) What does is binding a given
value to a task attribute. In the C++ world, the method to do that are call
bind, which is IMHO better that preset.
Also, this kind of static attribute-binding is useful indeed (I've actually
asked for it a few times), but is hardly a definition, and it's bad that it
forces you to rewrite the task name. I don't want to modify all my builds to
use just to take advantage of that feature.
Finally, , in term of functionality and not implementation, is
just a subset of in my opinion, and doesn't deserve Task status.
Much more useful IMO was be the ability to bind (or preset) values using
XPath expressions, to follow your example:
//javac/@debug = ${debug}
//javac/@deprecation = ${deprecation}
To just do it for an instance of Javac inside a particular target, do
//[EMAIL PROTECTED]'compile']/javac/@debug = true
I've always been annoyed to having to explicitly declare a bunch of task
attributes taking properties when sensible default values just to be able to
maybe override them.
So in conclusion, I'm +1 to the ability to bind values to task/type
attributes, but without requiring task name changes, and possibly with
requiring a task. I'm -0 to as it is.
A middle ground would be to have something like this, closer to your current
design:
So it yields no task rename, work for any valid tasks, and is more explicit.
>
> this defines a new task in the same way as except it
> uses a as a defintion of the task. The
> task has nested elements - param and element to allow the
> user to specify attributes and elements of the new task. These
> get substituted into the when the new task is
> run.
>
> example: (from a current project)
>
>
>
>
>
>
>
>
> outfile="${target.dir}/${target}">
>
>
>
>
>
>
>
>
>
>
> target.dir="${build.bin.dir}">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
I have much less problem with, but I concur with others that
overloading the behavior of ${name} is not good. This will be confusing to
me and other users that property expansion will not happen as usual at
definition time, but later on. I think we need another syntax for the macro
param/attributes, and keep the ${} working as usual.
I propose to use either:
* the XSL syntax (@name)
* or a Javadoc-like syntax [EMAIL PROTECTED] name}
Another advantage of the second form is that one would not need to
pre-declare the macro params (making it scripting-language-like), but on the
other hand, pre-declaring makes it more explicitly when reading the macro
what parameters it takes. If we force pre-declaration, we can then fail on
dereference to non-declared macro-param.
Should param be renamed attribute? , from the build writer point
of view, creates a new tasks, and we always speak of attributes and nested
elements, not params and nesting elements.
I'm -1 to if it keep the ${...} expansion form for
params/attributes.
I'm +1 to using nested s and s, with (@name)
expansion.
>
> Will I place these tasks in ant or ant-contrib ?
I use both, so I don't really mind ;-)
Thanks Peter, --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
The following tasks will be an excellent addition for the use Centipede does of Ant, so it's a big thumbs up! Presetdef can be used to redefine the most used Ant tasks adding the defaults taken from the descriptor we use. macrodef can make us finally create real macros that are not only targets, as instead has been done till now, so we can really make libraries of tasks defined through Ant buildfiles and not have them necessarily as targets. :-D peter reilly wrote, On 14/08/2003 11.20: Hi, I have written a couple of tasks to enable definition of new tasks in ant. (formally known as extendtype) this defines a new task or type based on a current ant task or type, with attributes or elements preset. example useage: may now be used as a task in the same way as but the attribute debug and deprecation will be preset. this defines a new task in the same way as except it uses a as a defintion of the task. The task has nested elements - param and element to allow the user to specify attributes and elements of the new task. These get substituted into the when the new task is run. example: (from a current project) Will I place these tasks in ant or ant-contrib ? Peter -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 12:28, Knut Wannheden wrote: > > A question: is a special task in the sense that it seems to be > able to suppress Ant from resolving properties for it when the task is > evaluated? Is there a mechanism which allows this to be done in custom > tasks as well? The trick is that MacroDef uses TaskContainer in a nested element. This is given UnknownElements before they are executed. MacroInstance then copies and walks the tree of unknownelements, modifing attribute values and text values. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
"User preferences" - nice scenario. - define your preferences with and in %user.home%/.ant/preferences.xml - include that file with in your actual buildfile So: +1 for placing in Ant Jan > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2003 1:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [new tasks] presetdef and macrodef > > > On Thu, 14 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > > Will I place these tasks in ant or ant-contrib ? > > Ant, they sound very useful. is a wonderful way to plug > in user preferences. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [new tasks] presetdef and macrodef
This looks excellent! It makes Ant a lot more flexible, but at the same
time also more compilcated to use. Buildfiles with (possibly nested)
s and s could be a lot harder to understand and
maintain. But if used correctly, probably easier!
A question: is a special task in the sense that it seems to be
able to suppress Ant from resolving properties for it when the task is
evaluated? Is there a mechanism which allows this to be done in custom
tasks as well?
--
knut
"peter reilly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thursday 14 August 2003 10:31, Conor MacNeill wrote:
> > Cool.
> >
> > I think these should go in Ant :-)
> Excellent.
> >
> > As you know I had thought about but I'm happy to
> > see you've done it. I think there is a slight property scoping issue
> > for the nested params. I had thought about a different syntax for
> > macro params (e.g. $[target]), perhaps hooked into a specific property
> > helper used for the macro scope.
>
> Initially I used $(target) but changed back to using
> ${target} as this is what people (including me) are used to.
> The substitution is done by the task itself and does not
> use the ant property infrastructure. The effect of this is to
> have a macro textual scope for the parameters (which look like
> properties).
>
> I had looked at having a task scope for properties, but this
> looked difficult to achieve.
>
> Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thu, 14 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote: > Will I place these tasks in ant or ant-contrib ? Ant, they sound very useful. is a wonderful way to plug in user preferences. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [new tasks] presetdef and macrodef
>-Message d'origine- >De : peter reilly [mailto:[EMAIL PROTECTED] >Envoyé : jeudi 14 août 2003 11:21 >À : [EMAIL PROTECTED] >Objet : [new tasks] presetdef and macrodef > > >Hi, >I have written a couple of tasks to enable definition of new tasks >in ant. > > (formally known as extendtype) [snip/] > > this defines a new task in the same way as except it > uses a as a defintion of the task. The > task has nested elements - param and element to allow the > user to specify attributes and elements of the new task. These > get substituted into the when the new task is > run. > [snip/] Hi, I was looking to this kind of features when I started my build file developement. I solved my need by doing dirty antcall. I am very happy to see this in ant core now, and I will adapt my build file as soon as possible ! :)) And it should solve some of my properties issues. Thanks, it is a good job! (Like everybody's one) I am using Ant for two years and i never find real blocker issues, or already closed in cvs. This kind of new features give me the desire for taking an active part. Thanks everybody! Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 10:31, Conor MacNeill wrote:
> Cool.
>
> I think these should go in Ant :-)
Excellent.
>
> As you know I had thought about but I'm happy to
> see you've done it. I think there is a slight property scoping issue
> for the nested params. I had thought about a different syntax for
> macro params (e.g. $[target]), perhaps hooked into a specific property
> helper used for the macro scope.
Initially I used $(target) but changed back to using
${target} as this is what people (including me) are used to.
The substitution is done by the task itself and does not
use the ant property infrastructure. The effect of this is to
have a macro textual scope for the parameters (which look like
properties).
I had looked at having a task scope for properties, but this
looked difficult to achieve.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Cool. I think these should go in Ant :-) As you know I had thought about but I'm happy to see you've done it. I think there is a slight property scoping issue for the nested params. I had thought about a different syntax for macro params (e.g. $[target]), perhaps hooked into a specific property helper used for the macro scope. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
