You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Reilly <pe...@corvil.com> on 2004/10/08 11:36:47 UTC
local properties
Hi,
I have had a proposal outstanding for a while for local properties:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
I would like to see them included in ant.
There has been a (lot) of discussions - see
http://marc.theaimsgroup.com/?t=108765926600001&r=1&w=2
http://marc.theaimsgroup.com/?t=107030281800001&r=1&w=2
http://marc.theaimsgroup.com/?t=106916956400008&r=1&w=2
My current feelings (and implemenation) is
1) Syntax
The proposal adds a local property to a enclosing target/taskcontainer.
Example:
<target name="example">
<local name="prop" value="a local value"/>
<echo>prop is ${prop}</echo>
</target>
<macrodef name="t2">
<attribute name="file"/>
<sequential>
<local name="dir"/>
<dirname property="dir" file="@{file}"/>
<mkdir dir="${dir}"/>
<touch file="@{file}"/>
</sequential>
</macrodef>
I think it is nicer to do this rather that having an explicit local
property container, or having special elements for different types
of structures (like for example a <local> element at the same level
as <attribute> in a <macrodef>).
2) Shadowing of properties
The proposal allows local properties to shadow normal and user properties.
I feel that this is necessary to allow macrodefs to be written without
them failing sometimes. This means that the following will work:
<project>
<import file="macros.xml"/>
<property name="dir" value="."/>
<t2 file="${user.home}/.ant/lib/js.jar"/>
</project>
ant -Ddir=/var/tmp
3) Extent of local properties
local properties will be inherited to child projects (if inheritall is
true).
Peter
Stephan Bodewig wrote:
> Things we need to consider IMHO:
> (1) Syntax
>Your proposal uses a <local> task that sets up a local scope for a
> named property until the enclosing target/sequential finishes. Jose
> Alberto suggested to use a <local> TaskContainer instead, something
> like
> <local>
> <local-property name="...."/>
> </local>
> which would essentially just add an explicit (and differently named)
> <seqential> to your proposal. I think I prefer the more explicit,
> even if more verbose syntax of the second form.
> (2) Shadowing of properties
> Your updated proposal ensures that local properties do not override
> "global" user properties. I think they shouldn't be allowed to
> override any outer scope properties at all.
> (3) Extent of local properties
> You make the local properties available to <script> - will they also
> be available for builds that get called with the <ant> family of tasks
> (assuming inheritall is true)? I think they should be.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties (what about PropertyHelper?)
Posted by Peter Reilly <pe...@apache.org>.
I think that the current way of doing propery helpers and hooks
is a bit wrong:
1) one can both replace the property helper (by setting a reference),
and one can put hooks in. Both are difficult to use and have bugs.
2) I would like to have recursive property resolution (even if it causes
some Backward Compatible issues.
3) The non-propageting of helpers to sub-projects is a bug I think.
The proposed localproperty changes should have no effect on custom property
helpers. However, the custom property helpers would not have the ability to
do localproperties, unless they inherited the base PropertyHelper
implemention
and the overridding code did not effect the local property handling code.
There should be no effect on hooks.
Jose's changes whould have none of these issues.
Peter
Wascally Wabbit wrote:
> QUESTIONS ON PropertyHelper (Ant 1.6+) ANT-dev mailing list:
>
> o Should PropertyHelper replacements honor currently attached
> hooks? What if a hook is attached and then the helper is
> unset (reset to the original Ant-installed one?) Should the
> (new) hooks be "moved" to the original helper?
>
> o Can we create a formal method that gets/sets propertyHelper w/o
> generating reference-replacement warnings?
>
> o What's the ant-dev position on recursive property resolution?
> Is it coming or is that value-added that one must put in one's
> own tasks?
>
> o How do we propagate replaced helpers to sub-projects? What
> about sub-builds?
>
> [NEW} Sooo how would custom PropertyHelpers and Hooks work with
> the selected <local> proposals?
>
> Thanks,
> The Wabbit
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
PropertyHelper (was Re: local properties (what about
PropertyHelper?))
Posted by Stefan Bodewig <bo...@apache.org>.
OK, separate answer since this really belongs on a separate thread.
On Fri, 08 Oct 2004, Wascally Wabbit <wa...@earthling.net>
wrote:
> o Should PropertyHelper replacements honor currently attached
> hooks?
I'm really sorry to admit that I'm not familiar enough with the code
to comment on it.
The things Peter said sound as if we needed to revamp the current
implementation to make it useful anyway. It simply moved below my
radar.
> o What's the ant-dev position on recursive property resolution?
Do you really think there is an official ant-dev position? Luckily we
are on the same page most of the time, but there is room for different
opinions. 8-)
> Is it coming or is that value-added that one must put in one's
> own tasks?
I'm still not convinced it would be useful enough to be part of the
default implementation. "Not convinced" != "I'd block any such attempt".
But AFAIU we need to change some things inside of Ant to enable
recursive property resolution, in particular the way we tokenize
strings when looking for properties. This is something IÄd support.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties (what about PropertyHelper?)
Posted by Wascally Wabbit <wa...@earthling.net>.
QUESTIONS ON PropertyHelper (Ant 1.6+) ANT-dev mailing list:
o Should PropertyHelper replacements honor currently attached
hooks? What if a hook is attached and then the helper is
unset (reset to the original Ant-installed one?) Should the
(new) hooks be "moved" to the original helper?
o Can we create a formal method that gets/sets propertyHelper w/o
generating reference-replacement warnings?
o What's the ant-dev position on recursive property resolution?
Is it coming or is that value-added that one must put in one's
own tasks?
o How do we propagate replaced helpers to sub-projects? What
about sub-builds?
[NEW} Sooo how would custom PropertyHelpers and Hooks work with
the selected <local> proposals?
Thanks,
The Wabbit
At 05:36 AM 10/8/2004, you wrote:
>Hi,
>
>I have had a proposal outstanding for a while for local properties:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
>
>I would like to see them included in ant.
>There has been a (lot) of discussions - see
>
>http://marc.theaimsgroup.com/?t=108765926600001&r=1&w=2
>http://marc.theaimsgroup.com/?t=107030281800001&r=1&w=2
>http://marc.theaimsgroup.com/?t=106916956400008&r=1&w=2
>
>My current feelings (and implemenation) is
>
>1) Syntax
>The proposal adds a local property to a enclosing target/taskcontainer.
>
>Example:
> <target name="example">
> <local name="prop" value="a local value"/>
> <echo>prop is ${prop}</echo>
> </target>
>
> <macrodef name="t2">
> <attribute name="file"/>
> <sequential>
> <local name="dir"/>
> <dirname property="dir" file="@{file}"/>
> <mkdir dir="${dir}"/>
> <touch file="@{file}"/>
> </sequential>
> </macrodef>
>
>I think it is nicer to do this rather that having an explicit local
>property container, or having special elements for different types
>of structures (like for example a <local> element at the same level
>as <attribute> in a <macrodef>).
>
>2) Shadowing of properties
>
>The proposal allows local properties to shadow normal and user properties.
>I feel that this is necessary to allow macrodefs to be written without
>them failing sometimes. This means that the following will work:
>
><project>
> <import file="macros.xml"/>
> <property name="dir" value="."/>
>
> <t2 file="${user.home}/.ant/lib/js.jar"/>
></project>
>
>ant -Ddir=/var/tmp
>
>3) Extent of local properties
>
>local properties will be inherited to child projects (if inheritall is true).
>
>Peter
>
>Stephan Bodewig wrote:
>>Things we need to consider IMHO:
>
>>(1) Syntax
>
>>Your proposal uses a <local> task that sets up a local scope for a
>>named property until the enclosing target/sequential finishes. Jose
>>Alberto suggested to use a <local> TaskContainer instead, something
>>like
>
>><local>
>> <local-property name="...."/>
>></local>
>
>>which would essentially just add an explicit (and differently named)
>><seqential> to your proposal. I think I prefer the more explicit,
>>even if more verbose syntax of the second form.
>
>>(2) Shadowing of properties
>
>>Your updated proposal ensures that local properties do not override
>>"global" user properties. I think they shouldn't be allowed to
>>override any outer scope properties at all.
>
>>(3) Extent of local properties
>
>>You make the local properties available to <script> - will they also
>>be available for builds that get called with the <ant> family of tasks
>>(assuming inheritall is true)? I think they should be.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>On Wed, 20 Oct 2004, Peter Reilly <pe...@corvil.com> wrote:
>
>
>
>>Ok, I am modifying the local patch to do:
>>
>><target name="example">
>> <let>
>> <localproperty name="prop" value="a local value"/>
>> <echo>prop is ${prop}</echo>
>> </let>
>></target>
>>
>>
>
>This is what you get when you say "do as you please, I don't have time
>to fight for my solution"? I should try it more often ;-)
>
>
Well, I still think that implicit containers are the best solution, but
when I
was coding <localproperty> for <macrodef> I saw that It would be
annoying for thirdparty tasks to implement something similiar - so it
would be better to have a method in ant core to provide local properties
without a need to code for them. This can be provided by a localproperty
container.
Peter
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Matt Benson <gu...@yahoo.com>.
[EDITED]
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 20 Oct 2004, Matt Benson
> <gu...@yahoo.com> wrote:
> > So that instead of declaring which properties do
> NOT
> > remain, we declare which properties DO remain.
>
> What would be the gain? How would this simplify
> things?
>
> Less pollution of the global property name space? I
Yes, that...
> wouldn't expect
> people to use any let/scope/whatever container
> unless they really
> wanted local properties - but that doesn't mean they
> want all their
> properties to be local. I'm not sure which behavior
> would be more
> common and thus should be the default.
>
> Any other benefits?
>
Perhaps this is my literal-minded nitpicky-ness coming
out; the behavior I suggest just seems to
more-accurately depict the nature of a conceptual
"scope". It also aligns with the way variable scopes
work in Java, for example.
> Stefan
-Matt
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Stefan Bodewig <bo...@apache.org>.
[... skipping the name discussion since I'm responsible for many
misnomers in Ant already 8-) ...]
On Wed, 20 Oct 2004, Matt Benson <gu...@yahoo.com> wrote:
> So that instead of declaring which properties do NOT
> remain, we declare which properties DO remain.
What would be the gain? How would this simplify things?
Less pollution of the global property name space? I wouldn't expect
people to use any let/scope/whatever container unless they really
wanted local properties - but that doesn't mean they want all their
properties to be local. I'm not sure which behavior would be more
common and thus should be the default.
Any other benefits?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> This is what you get when you say "do as you please,
> I don't have time
> to fight for my solution"? I should try it more
> often ;-)
I originally thought about a "scope" Sequential
subclass as well. In fact, when I got into my email
today I planned to speak up in favor of it... I don't
think we should be implementing one thing now with the
promise of something better later. Let's just get it
right the first time. So, that said, what do we think
of this alteration:
<let|scope|localpropertyscope|etc>
<persist property="foo" />
<persist>
<propertyset />
</persist>
<your-task-here />
</let|scope|localpropertyscope|etc>
So that instead of declaring which properties do NOT
remain, we declare which properties DO remain.
Or, if I can't sell that, at least make the behavior
configurable via an attribute and support <persist>
(or whatever) as well as <local>.
Now how 'bout that?
-Matt
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 20 Oct 2004, Peter Reilly <pe...@corvil.com> wrote:
> Ok, I am modifying the local patch to do:
>
> <target name="example">
> <let>
> <localproperty name="prop" value="a local value"/>
> <echo>prop is ${prop}</echo>
> </let>
> </target>
This is what you get when you say "do as you please, I don't have time
to fight for my solution"? I should try it more often ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Peter Reilly <pe...@corvil.com>.
Stefan Bodewig wrote:
>Nicer? Maybe. I still think a special task container would be
>cleaner since it provided explicit scoping and might even help us
>route around the "custom PropertyHelpers problem". Something like
>
><target name="example">
> <let>
> <local name="prop" value="a local value"/>
> <echo>prop is ${prop}</echo>
> </let>
></target>
>
>
>
Ok, I am modifying the local patch to do:
<target name="example">
<let>
<localproperty name="prop" value="a local value"/>
<echo>prop is ${prop}</echo>
</let>
</target>
So, Task, Target, Parallel do not get changed.
I also think that the nested localproperty for the macrodef task can be
dropped
initially. It would be easier to explain just one container for local
properties/
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Peter Reilly <pe...@apache.org>.
Jack J. Woehr wrote:
>Stefan Bodewig wrote:
>
>
>
>>Nor the other way around. You've convinced me, we need shadowing.
>>
>>
>
>Shadowing, or a definition stack for each definition?
>
That is the way the local patch works.
But it is not as clean as it should be, in that user properties and normal
properties are not in the stack.
Peter
>That's the way m4 works
>[ pushdef() ] and I've implemented that in object Forth.
>
>--
>Jack J. Woehr # Libertarian candidate
>PO Box 51, Golden, CO 80402 # Colorado 6th US House District
>http://www.well.com/~jax/2004 # Vote November 2, 2004
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by "Jack J. Woehr" <ja...@well.com>.
Stefan Bodewig wrote:
> Nor the other way around. You've convinced me, we need shadowing.
Shadowing, or a definition stack for each definition? That's the way m4 works
[ pushdef() ] and I've implemented that in object Forth.
--
Jack J. Woehr # Libertarian candidate
PO Box 51, Golden, CO 80402 # Colorado 6th US House District
http://www.well.com/~jax/2004 # Vote November 2, 2004
Re: local properties
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 15 Oct 2004, Peter Reilly <pe...@apache.org> wrote:
> Since we are really only worried about the macrodef usecase, we
> could initially just deal with this using the syntax:
>
> <macrodef name="t2">
> <attribute name="file"/>
> <localproperty name="dir"/>
> <sequential>
> <dirname property="dir" file="@{file}"/>
> <mkdir dir="${dir}"/>
> <touch file="@{file}"/>
> </sequential>
> </macrodef>
>
> I.e have a local nested element for <macrodef> - this syntax has
> of course been discussed previously.
Hmm, OK.
> The local properties should I think be in thread-local storage to
> avoid conflicts between multiple threads, so I think that
> PropertyHelper needs to be modified to do this.
Yes, as it would need for my (not-coded) <let> container. It
basically uses the same approach.
>>>2) Shadowing of properties
>>
>>Can you expand on this please? Whyt kind of macros would require
>>shadowing in order to be writable?
>>
> There are two reasons for this
>
> 1) Macrodefs are normally hidden - say in imported files or in an
> antlib, so one may not know what names they use for local
> properties.
Nor the other way around. You've convinced me, we need shadowing.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>Trying to consolidate a few answers since I'm very late to the party
>anyway.
>
>On Fri, 08 Oct 2004, Peter Reilly <pe...@corvil.com> wrote:
>
>
>>I have had a proposal outstanding for a while for local properties:
>>
>
>a long while.
>
>My preferences haven't changed much over time, but I'm far too busy to
>help getting this to a conclusion. My current work schedule would
>prolong any kind of discussion for an unreasonable amount of time.
>
>I think we need to address the problem of temporary properties inside
>macros in some way and prefer a solution that doesn't leave us with
>tons of new and unused properties. If I can't get it my way, read "if
>I can't convince you", I'd rather see your solution implemented than
>keep the status quo.
>
>
>>1) Syntax The proposal adds a local property to a enclosing
>>target/taskcontainer.
>>
>>Example:
>> <target name="example">
>> <local name="prop" value="a local value"/>
>> <echo>prop is ${prop}</echo>
>> </target>
>>
>> <macrodef name="t2">
>> <attribute name="file"/>
>> <sequential>
>> <local name="dir"/>
>> <dirname property="dir" file="@{file}"/>
>> <mkdir dir="${dir}"/>
>> <touch file="@{file}"/>
>> </sequential>
>> </macrodef>
>>
>>I think it is nicer to do this rather that having an explicit local
>>property container,
>>
>
>Nicer? Maybe. I still think a special task container would be
>cleaner since it provided explicit scoping and might even help us
>route around the "custom PropertyHelpers problem". Something like
>
><target name="example">
> <let>
> <local name="prop" value="a local value"/>
> <echo>prop is ${prop}</echo>
> </let>
></target>
>
>but I'm repeating myself. I have no new arguments to add.
>
Since we are really only worried about the macrodef usecase, we could
initially just deal with this using the syntax:
<macrodef name="t2">
<attribute name="file"/>
<localproperty name="dir"/>
<sequential>
<dirname property="dir" file="@{file}"/>
<mkdir dir="${dir}"/>
<touch file="@{file}"/>
</sequential>
</macrodef>
I.e have a local nested element for <macrodef> - this syntax has
of course been discussed previously. We can leave the gate open
to allow other third-party containers to use local properties -
like the <let> container in your example, or the <for> task from
ant-contrib or the <foreach> task from antxtras. This could be done
by providing the java api to create localproperties. Implementing
all containers to support local properties could be at a later
stage - if there is a demand (unlikely).
The local properties should I think be in thread-local storage to
avoid conflicts between multiple threads, so I think that PropertyHelper
needs to be modified to do this.
>>2) Shadowing of properties
>>
>>The proposal allows local properties to shadow normal and user
>>properties. I feel that this is necessary to allow macrodefs to be
>>written without them failing sometimes.
>>
>
>Can you expand on this please? Whyt kind of macros would require
>shadowing in order to be writable?
>
There are two reasons for this
1) Macrodefs are normally hidden - say in imported files or in an antlib,
so one may not know what names they use for local properties. Normal
programming languages allow scoped variable names to override the global
names to allow this isolation. If user properties names overrode the
localnames, the <t2/> example above would really not be able to use
a nice small name like "dir" for the localproperty name, but would have
to adopt a convention like "t2_dir" for the name, and hope that no one
will use ant -Dt2_dir="not a nice dir". Jose's approach does not have
this problem - but it does come at a cost (hidden names).
2) the user explictity say that the name is a local property. It seems
reasonable to expect that the property that is used is local and not
a global
property (this is probally the same argument as 1) :-[ )
>
>>3) Extent of local properties
>>
>>local properties will be inherited to child projects (if inheritall
>>is true).
>>
>
>Fine with me.
>
>On Fri, 8 Oct 2004, Jose Alberto Fernandez <ja...@cellectivity.com>
>wrote:
>
>
>>>2) All these uniquely named properties go on living after
>>> the macro has executed. That pollutes the namespace.
>>>
>>Yes it does. But I still have to see a good argument on why shall
>>that bother anyone. Unless you are talking about millions of
>>executions within one project context.
>>
>
>Hmm, ask Steve how long a SmartFrog instance is running. And AFAIU
>NetBeans 4 runs a single instance of Ant as long as the IDE is
>running. This may really lead to quite a few properties at the end of
>the day, in particular if you need to pass them to a forked JUnit VM
>or down to a child build with inheritall set to true.
>
Jose's solution could be modified to remove the properties on exit
from the macrodef. - but this would need to be made thread-safe.
>
>>My worries with these other solutions are that they not only touch
>>macrodef and propertyHelper, they modify target, ant, sequential,
>>parallel,and several other tasks.
>>
>
>That's why I'd prefer the explicit TaskContainer. It shouldn't be
>necessary to touch target, for example.
>
I do not agree, but like I said above this is not needed for the
macrodef use case
so it can be dropped from the proposal.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: local properties
Posted by Stefan Bodewig <bo...@apache.org>.
Trying to consolidate a few answers since I'm very late to the party
anyway.
On Fri, 08 Oct 2004, Peter Reilly <pe...@corvil.com> wrote:
> I have had a proposal outstanding for a while for local properties:
a long while.
My preferences haven't changed much over time, but I'm far too busy to
help getting this to a conclusion. My current work schedule would
prolong any kind of discussion for an unreasonable amount of time.
I think we need to address the problem of temporary properties inside
macros in some way and prefer a solution that doesn't leave us with
tons of new and unused properties. If I can't get it my way, read "if
I can't convince you", I'd rather see your solution implemented than
keep the status quo.
> 1) Syntax The proposal adds a local property to a enclosing
> target/taskcontainer.
>
> Example:
> <target name="example">
> <local name="prop" value="a local value"/>
> <echo>prop is ${prop}</echo>
> </target>
>
> <macrodef name="t2">
> <attribute name="file"/>
> <sequential>
> <local name="dir"/>
> <dirname property="dir" file="@{file}"/>
> <mkdir dir="${dir}"/>
> <touch file="@{file}"/>
> </sequential>
> </macrodef>
>
> I think it is nicer to do this rather that having an explicit local
> property container,
Nicer? Maybe. I still think a special task container would be
cleaner since it provided explicit scoping and might even help us
route around the "custom PropertyHelpers problem". Something like
<target name="example">
<let>
<local name="prop" value="a local value"/>
<echo>prop is ${prop}</echo>
</let>
</target>
but I'm repeating myself. I have no new arguments to add.
> 2) Shadowing of properties
>
> The proposal allows local properties to shadow normal and user
> properties. I feel that this is necessary to allow macrodefs to be
> written without them failing sometimes.
Can you expand on this please? Whyt kind of macros would require
shadowing in order to be writable?
> 3) Extent of local properties
>
> local properties will be inherited to child projects (if inheritall
> is true).
Fine with me.
On Fri, 8 Oct 2004, Jose Alberto Fernandez <ja...@cellectivity.com>
wrote:
>> 2) All these uniquely named properties go on living after
>> the macro has executed. That pollutes the namespace.
>
> Yes it does. But I still have to see a good argument on why shall
> that bother anyone. Unless you are talking about millions of
> executions within one project context.
Hmm, ask Steve how long a SmartFrog instance is running. And AFAIU
NetBeans 4 runs a single instance of Ant as long as the IDE is
running. This may really lead to quite a few properties at the end of
the day, in particular if you need to pass them to a forked JUnit VM
or down to a child build with inheritall set to true.
> My worries with these other solutions are that they not only touch
> macrodef and propertyHelper, they modify target, ant, sequential,
> parallel,and several other tasks.
That's why I'd prefer the explicit TaskContainer. It shouldn't be
necessary to touch target, for example.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org