DO NOT REPLY [Bug 23942] - Addition of a local property

2007-08-22 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942


[EMAIL PROTECTED] changed:

   What|Removed |Added

Attachment #8631 is|0   |1
   obsolete||
Attachment #8632 is|0   |1
   obsolete||
Attachment #8652 is|0   |1
   obsolete||
Attachment #9164 is|0   |1
   obsolete||
Attachment #9263 is|0   |1
   obsolete||
  Attachment #12994|0   |1
is obsolete||
  Attachment #13000|0   |1
is obsolete||
  Attachment #13157|0   |1
is obsolete||
  Attachment #13158|0   |1
is obsolete||
  Attachment #13220|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-08-22 02:15 ---
Created an attachment (id=20688)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20688action=view)
New patch against trunk using new PropertyHelper delegates

This is a new patch.
Main differences from previous:
  1) it does not leak memory (hopefully)
  2) copy of the stack has is only done in parrallel and not
 for each and every new thread.
  3) the local properties will not be inherited in sub-projects
  4) stack design has improved and code is easier to follow
  5) use separate java files for each class
  6) use new PropertyHelper delegates

This patch has local properties per scope - target element, sequential element
and macrodef.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-26 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 08:49 ---
Jose, I do not see the problem with your example.
A/ uses a property (say X) to export some output - therefore it
must be a condition of the user of A/ to know this.
B/ declares X to be local and then calls A/, B/ may now use
the output of A/ without effecting other users of A/.

So for example:
A/
B/
MoreA/
MoreA will use X as set by A/ and not by the A/ called
by B/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-26 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 08:52 ---
Created an attachment (id=13220)
new patch - fold local properties into properties, Project.getProperties() now 
works as expected

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-26 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 11:59 ---
This idea that everyone must know ALL the details about ANY software 
module that we refer to in our code, is a dead one in softwareland except for 
ANT. One of the keys of building reusable software is that I must be able to 
build backboxes and only know about relevant input/outputs.

The other one, is to be able to compose modules toguether and then hide their 
communication details (blackbox it) and create a new module that way.
Wehave not even scratched the surface on what can be done with ANTLIBS and 
macrodefs. To expect users to need to know about every usage or communication 
all the way down the stack makes for very bad reusability.

This is an inherit problem in ANT at the moment, but one that we should try to 
solve, if we want ANTLIBS to be really successful.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-22 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 12:03 ---

True, if I wrote the macro, but if I am using something from an antlib, lets 
say: A/ and moreA/. Two tasks defined in an antlib. I shouldn't need to 
know whether they are macros, tasks in beanshell, java or whatever. I should 
be able to just use them. Now, this two tasks happen to communicate with each 
other. For example, A/ will test some condition and moreA/ will use this 
result to do something clever. I should not need to know that, the only thing 
I should know is that I must call A/ before I call moreA/.

But just because I decided to call A/ inside my B/ then the whole thing 
falls appart. :-(

Now, my comment about scopes, was that maybe in A I could say scope=antlib
and that will make the scope of the property that of the antlib, which means 
that only things defined on that antlib will see it. Now that would give
a lot of abstraction power. But it is yet another hurdle for any proper 
implementation. Notice that this would have to work not only for macros but 
also for regular tasks with some additional API that allows specifying the 
scope when I call Project.setNewProperty().

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 00:25 ---
Well since I used let to define something completely different which I may 
want to preserve. I may also want a different name for this new context 
declaration. Some ideas may be: block/ or local or yes scope.

Sorry, Dominique if I misunderstood you naming issue to refer to mine let 
rather than Peter's. I still think that let is fine for mine :-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 10:57 ---
As I said before, I would prefer an implicit local property container - target
and any task container.

If there is to be an explicit local property container, I do not care what name
it is, localpropertyscope is probally the best name.

let is used in emacs lisp for example:
  (let* ((type-and-name (jdok-extract-type-and-name declaration))
 (arglist   (jdok-extract-arglist   declaration))
 (throws(jdok-extract-throwsdeclaration))
 (type  (car type-and-name))
 (name  (cdr type-and-name)))
(if (or type name arglist throws)
(vector type name arglist throws

but it is probally a little confusing as let is also used in
other languages like basic.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 14:36 ---
I also should have made the distinction between Jose's and Peter's lets.  And 
I can accept Jose's assertion that let is appropriate enough a name for his.

To continue in my search for feedback on the idea of declaring only those 
properties which persist beyond the theoretical local scope, let me throw this 
statement out:

If an explicit TaskContainer is used for local properties, it makes sense to 
declare the properties that are NOT local; if scope is made implicit to the 
nearest enclosing TaskContainer, it makes sense to declare which properties ARE 
local.  Opinions?!  ;)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 15:29 ---
macrodef name=A
 
 property name=fooA .../
 
/macrodef

macrodef name=B
 ...
 localpropertyscope
   localproperty name=fooB value=XB/
   A/
 localpropertyscope
 ...
/macrodef

 B/
 echo message=${fooA}/

What should be the correct answer. Assume that B/ does not know about A's 
implementation.

Why should that be the correct answer. 
Would like to hear from those advacating for default local and default global.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 16:36 ---
The localscope patch uses dynamic scoping (like lisp) and not static scoping 
(like C) so the result of calling 
 B/
 echo message=${fooA}/

is whatever A is set fooA to. fooA is a global property - it has not
been shaddowed by a local property.
Another example is:

  target name=j
macrodef name=A
  sequential
property name=fooA value=splatto/
property name=fooB value=splatto/
  /sequential
/macrodef

macrodef name=B
  sequential
localpropertyscope
  localproperty name=fooB value=XB/
  A/
/localpropertyscope
  /sequential
/macrodef

B/
echo message=fooA is ${fooA}/
echo message=fooB is ${fooB}/
  /target

Which will generate:
fooA is splatto
fooB is ${fooB}

the use of fooB in macroA will find the local property decalared
in macroB and attempt to set it (as properties can only be
set once, this will not succeed), and not create a global property fooB.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 16:40 ---
I am advocating an explicit scope block with properties defaulting to local 
scope, so my answer to Jose's setup would be no output; i.e. fooA is not set.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 17:45 ---

Matt, how many builds will that break? Notice that A/ may have come from 
some other antlib and hence expects nothing about local scopes. It may be 
setting a property for some other macro in that antlib. On the other hand b/ 
knows nothing about the private communication (implementation detail) between 
those macros. But it needs a local scope for its own properties. So even if 
there is no name collisions we break the code in a/.

BTW, one of the problems I have with all this shadowing is that for a project 
to be correct now I need to know the details of the implementations of all the 
macros in use, because I may shadow by accident a name used by someone else. 
In some 3rd party antlib that I do not know about.

Of course my proposal did not have that problem ;-) Although I recognized that 
name collisions were there already in ANT. Can that be solved with a scope ? 
Hu.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-21 18:00 ---
But by that example, if you call A expecting it to set fooA, and you are the 
author of B, you would know you must declare that fooA transcend the scope 
imposed upon it by the accident of its lineage... ;)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 18:18 ---
Created an attachment (id=13157)
New patch - remove containers, need special container, fix threading

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 18:19 ---
Created an attachment (id=13158)
The local property container - let

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 18:23 ---
I have uploaded a new patch and a new task let.
This patch still uses the Local java file.
This patch changes the method used to declare local properties.
They are now in a separate container - let and declared
with localproperty

let
  localproperty name=local value=a local property/
  echolocal is ${local}/echo
/let

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 19:26 ---
Are Dominique and I alone in our distaste for the let name?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 20:03 ---
After you mentioned it, I also do not like let. Can we use an implicit 
current scope?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 21:16 ---
Now that's funny.  That's what Peter originally wanted.  I don't like that 
either, personally.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 21:51 ---
Why not to make let more useful then. For example:

local properties=name1,name2,...
  property name=name1 value=XXX/
/local

At least in this case it defines local properties.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-20 22:07 ---
Personally I think I like the declare a scope and then declare only the 
properties that persist beyond that scope more than declare a scope and its 
local properties.  I think it's more likely you may use three intermediate 
properties to arrive at one result than vice-versa.

$0.03

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-09 00:53 ---
Created an attachment (id=13000)
Macrodef let element to use for local properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-08 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 09:01 ---
Created an attachment (id=12994)
update of local patch, allow local properties to hide user properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-08 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 10:52 ---
People, I think I have a much more clean solution to the isue of complex
macros and its necessary properties that does not affect the core of ANT at 
all.
It is a complete local solution to macrodef without spillovers. I cannot post 
it nor commit it until tonight since it is in my machine at home.

The basic approach is something I proposed here some time ago. Providing a 
let element in macrodef which defined guaranteed unique names for 
properties. The syntax is very simple:

macrodef name=checkCondition
 let name=isTrue
 element name=cond
 sequential
   condition property=@{isTrue} value=Hurray!!!
 cond/
   /condition
   echo if=@{isTrue}The condition is true: [EMAIL PROTECTED]/echo
   echo unless=@{isTrue}The condition is false/echo
 sequential
/macro

The macro above will be used as follows:

 checkCondition
   cond
available file=${myfile}/
   /cond
 /checkCondition

And it will print whether the condition is true or not.

As you can see from the style of writing, let/ just defines an attribute
( @{..} syntax) whose value is a name guaranteed to be unique within the JVM.
You can use this name as the name for a property, or whatever else.

Everytime you execute the macro, a new value is assigned to the let attribute
and you can have as many as you want. This is all the machinery you need to
write as complicated macros as you want, using recurtion or whatever.
And since it does not touch and does not rely on changes to the CORE there 
are no possible BC issues. 

So let me submit my proposal tonight and we can talk about any misgivings
on the particulars.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-08 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 16:07 ---
That brings us back to the properties pollution debate, does it not?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-10-07 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-10-07 19:34 ---
*** Bug 31586 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-06-23 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-23 17:49 ---
*** Bug 21721 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-01-22 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-01-22 16:21 ---
What are the current plans for local?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2004-01-22 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2004-01-22 18:44 ---
I am leaving this at the moment until 1.6 settles down a
bit. I will update the patch soon.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-11-24 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-11-24 13:26 ---
Created an attachment (id=9263)
Patch against ant_1_6 head and cvs head

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-11-24 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-11-24 13:29 ---
As per Jake's report (thanks) made a new patch:
 * which works against cvs head and ANT_16_BRANCH head
 * modified addLocalProperty back to be (String, Object) so
   that Local.java should work without modifification.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-11-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 15:14 ---
Created an attachment (id=9164)
Update to the local patch

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-11-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 15:19 ---
Made a new patch against the current cvs.
Changes:
  * do not allow local properties to override user properties
  * add local properties to the symbols exported to script
  * add a local/ element to macrodef to allow it to
specify use of a local property in place of a
attribute

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-11-14 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-11-14 18:42 ---
This functionality would be especially useful in concert with macrodefs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-10-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-21 11:16 ---
Created an attachment (id=8652)
Allow ant/antcall to inherit local properties, provide optional attribute

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:47 ---
Created an attachment (id=8631)
Diff against HEAD for local property

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:48 ---
Created an attachment (id=8632)
the local task

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 23942] - Addition of a local property

2003-10-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:51 ---
I have posted the patches, one
thing to work on is the possible
inheritances of local properties to
antcall and ant.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]