RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

No matter what syntax we decide to use we need
to provide an escape sequence for it.
Even if we know of no conflict today, tomorrow one 
may show up. Hence we should face the music head on.

I think matching other languages (like XSLT or something)
is really wrong.

My only reason for suggesting a syntax starting with
$ is that we already have rules for escaping them,
if we use other very different syntax (like [EMAIL PROTECTED] ) 
we need to invent some new syntax for escaping it.

This is why I want something simple and close to what ANT already
has, so that we can move on quicly on this issue that has been
dragging us on for way too long.

Jose Alberto

> -Original Message-
> From: Steve Cohen [mailto:[EMAIL PROTECTED] 
> Sent: 17 November 2003 18:50
> To: Ant Developers List
> Subject: RE: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Another non committer here.
> I don't like $(x) because it looks too much like ${x}, 
> although I suppose I could get used to that.  Therfore, I am 
> drawn to @{x}.  ${attribute:x} is possible but way too much 
> typing for my taste. Abbreviated to ${att:x} or ${attrib:x} 
> my negativity level goes down accordingly.
> 
> Before "voting", though, could someone list all the 
> conflicting usages with other systems that ant must interface with.
> 
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 17, 2003 12:10 PM
> To: Ant Developers List
> Subject: Re: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> OK, how do we want to implement  attributes:
>   current
>  [ ] as textual substitution~ 4
>  [ ] as "real" Ant properties   ~ 2
> 
> undecided   ~ 1
> 
> If macrodef attribute are to be implements as substitutions, 
> what should be the notation? (where x is the attribute name)
> 
>  [ ] as ${x} (look like ant properties)
>  [ ] as $(x) 
>  [ ] as @x
>  [ ] as ${attribute:x}
>  [ ] as @{x}
>  [ ] some thing else
> 
> 
> 
> -
> 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]
> 
> 

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

DO NOT REPLY [Bug 24761] - specify a target to be executed if error occurs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24761

specify a target to be executed if error occurs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 07:52 ---


*** This bug has been marked as a duplicate of 17973 ***

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

DO NOT REPLY [Bug 17973] - A target just like a target

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=17973

A  target just like a  target

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 07:52 ---
*** Bug 24761 has been marked as a duplicate of this bug. ***

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

RE: Property resolution in a task

[Jan . Materne]

> > Ok, that comes from a guy who works more on DOM-Nodes than me (=nothing)
:-)
> > 
> > Should we add that to Project class? (If we are allowed to do that)
> 
> sure -as long as we also have a test for it :)


Of course - only with test :-)
Ok, I will try that.


Jan

RE: macrodef - do attributes as properties or substitutions

[Jan . Materne]

> > 
> > 
> > 
> > 
> > 
> 
> I don't think we should need any special cludges just to support this
> usecase. 8-)
> 
> Give two a completely bogus, impossible to be used in any real world
> usage value and check for that.  Should be easier than comparing it to
> a literal ${one} or @one or whathever.
> 
> 
> 
>
> default="nobody-with-a-sane-mind-would-ever-want-to-use-this-value"/>
> 

Nice idea - usually such nice words don´t come into my mind when I´m
programming :-)
But the string comparison would be easier.

Jan

RE: [VOTE] macrodef - do attributes as properties or substitution s

[Jan . Materne]

> If macrodef attribute are to be implements as substitutions, what
> should be the notation? (where x is the attribute name)
> 
  [ ] as ${x} (look like ant properties)  confusion with 'real'
properties
  [ ] as $(x) to close to A
  [ ] as @x   I miss the brackets
  [ ] as ${attribute:x}   too long
  [X] as @{x} ok, close to A but seeable
different
  [ ] some thing else nothing in my mind to that


- a construct according to  seems to be
too long
- other XSLT constructs:  $attribname, @attribname: I miss the brackets ...

- escape sequence for E could be: @@{x}; doubling the special character is
widely used


Jan

Re: [VOTE] macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Mon, 17 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> OK, how do we want to implement  attributes:
>   current
>  [ ] as textual substitution~ 4
>  [ ] as "real" Ant properties   ~ 2
> 
> undecided   ~ 1

only counting the "binding" votes would result in 1/2/1, so neither
choice has received enough binding votes by now.  Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.

> If macrodef attribute are to be implements as substitutions, what
> should be the notation? (where x is the attribute name)
> 
>  [ ] as ${x} (look like ant properties)

-1, too confusing.

>  [ ] as @x

-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.




is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?

>  [ ] as ${attribute:x}

-1 - still looks too much like a property and collides with existing
properties that's name starts with "attribute:" (unlikely but
possible).

>  [ ] as $(x) 
>  [ ] as @{x}

either one works for me - as well as [EMAIL PROTECTED]

Stefan

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

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroInstance.java

[peterreilly]

peterreilly2003/11/18 02:51:41

  Modified:docs/manual/CoreTypes antlib.html
   src/main/org/apache/tools/ant IntrospectionHelper.java
ProjectHelper.java Task.java UnknownElement.java
   src/main/org/apache/tools/ant/helper ProjectHelper2.java
   src/main/org/apache/tools/ant/taskdefs MacroInstance.java
  Log:
  Implement namespace uri scoping
  nested elements of types/tasks use the same NS uri as the task/type.
  also cleanup macrodef attribute handling
  
  Revision  ChangesPath
  1.6   +3 -3  ant/docs/manual/CoreTypes/antlib.html
  
  Index: antlib.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTypes/antlib.html,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- antlib.html   14 Oct 2003 15:30:40 -  1.5
  +++ antlib.html   18 Nov 2003 10:51:41 -  1.6
  @@ -133,9 +133,9 @@
 

   
  -
  -   
  -
  +
  +   
  +

 
  
  
  
  
  1.68  +70 -2 
ant/src/main/org/apache/tools/ant/IntrospectionHelper.java
  
  Index: IntrospectionHelper.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/IntrospectionHelper.java,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- IntrospectionHelper.java  6 Nov 2003 09:04:08 -   1.67
  +++ IntrospectionHelper.java  18 Nov 2003 10:51:41 -  1.68
  @@ -642,6 +642,52 @@
   return nc;
   }
   
  +private NestedCreator getNestedCreator(
  +Project project, String parentUri, Object parent,
  +String elementName) throws BuildException {
  +
  +String uri = ProjectHelper.extractUriFromComponentName(elementName);
  +String name = 
ProjectHelper.extractNameFromComponentName(elementName);
  +
  +NestedCreator nc = null;
  +if (uri.equals(parentUri)) { //  || uri.equals("")) {
  +nc = (NestedCreator) nestedCreators.get(
  +name.toLowerCase(Locale.US));
  +}
  +if (nc == null) {
  +nc = createAddTypeCreator(project, parent, elementName);
  +}
  +if (nc == null && parent instanceof DynamicConfigurator) {
  +DynamicConfigurator dc = (DynamicConfigurator) parent;
  +final Object nestedElement = 
dc.createDynamicElement(elementName);
  +if (nestedElement != null) {
  +nc = new NestedCreator() {
  +public boolean isPolyMorphic() {
  +return false;
  +}
  +public Class getElementClass() {
  +return null;
  +}
  +
  +public Object getRealObject() {
  +return null;
  +}
  +
  +public Object create(
  +Project project, Object parent, Object ignore) {
  +return nestedElement;
  +}
  +public void store(Object parent, Object child) {
  +}
  +};
  +}
  +}
  +if (nc == null) {
  +throwNotSupported(project, parent, elementName);
  +}
  +return nc;
  +}
  +
   /**
* Creates a named nested element. Depending on the results of the
* initial introspection, either a method in the given parent instance
  @@ -692,6 +738,7 @@
* for an element of a parent.
*
* @param project  Project to which the parent object belongs.
  + * @param parentUriThe namespace uri of the parent object.
* @param parent   Parent object used to create the creator object to
* create and store and instance of a subelement.
* @param elementName  Name of the element to create an instance of.
  @@ -699,8 +746,9 @@
*/
   
   public Creator getElementCreator(
  -Project project, Object parent, String elementName) {
  -NestedCreator nc = getNestedCreator(project, parent, elementName);
  +Project project, String parentUri, Object parent, String 
elementName) {
  +NestedCreator nc = getNestedCreator(
  +project, parentUri, parent, elementName);
   return new Creator(project, parent, nc);
   }
   
  @@ -714,6 +762,26 @@
*/
   public boolean supportsNestedElement(String elementName) {
   return nestedCreators.containsKey(elementName.toLowerCase(Locale.US))
  +|| 

Re: Ant 1.6 and namespace

[Stefan Bodewig]

On Mon, 17 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> We could modify namespace processing to ignore attributes not in the
> "right" namespace.

+1

Stefan

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

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroInstance.java

[peterreilly]

peterreilly2003/11/18 03:29:07

  Modified:docs/manual/CoreTypes Tag: ANT_16_BRANCH antlib.html
   src/main/org/apache/tools/ant Tag: ANT_16_BRANCH
IntrospectionHelper.java ProjectHelper.java
Task.java UnknownElement.java
   src/main/org/apache/tools/ant/helper Tag: ANT_16_BRANCH
ProjectHelper2.java
   src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
MacroInstance.java
  Log:
  Sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.4   +3 -3  ant/docs/manual/CoreTypes/antlib.html
  
  Index: antlib.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTypes/antlib.html,v
  retrieving revision 1.3.2.3
  retrieving revision 1.3.2.4
  diff -u -r1.3.2.3 -r1.3.2.4
  --- antlib.html   14 Oct 2003 15:30:42 -  1.3.2.3
  +++ antlib.html   18 Nov 2003 11:29:06 -  1.3.2.4
  @@ -134,9 +134,9 @@
 

   
  -
  -   
  -
  +
  +   
  +

 
  
  
  
  
  No   revision
  No   revision
  1.65.2.3  +70 -2 
ant/src/main/org/apache/tools/ant/IntrospectionHelper.java
  
  Index: IntrospectionHelper.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/IntrospectionHelper.java,v
  retrieving revision 1.65.2.2
  retrieving revision 1.65.2.3
  diff -u -r1.65.2.2 -r1.65.2.3
  --- IntrospectionHelper.java  6 Nov 2003 09:07:51 -   1.65.2.2
  +++ IntrospectionHelper.java  18 Nov 2003 11:29:06 -  1.65.2.3
  @@ -642,6 +642,52 @@
   return nc;
   }
   
  +private NestedCreator getNestedCreator(
  +Project project, String parentUri, Object parent,
  +String elementName) throws BuildException {
  +
  +String uri = ProjectHelper.extractUriFromComponentName(elementName);
  +String name = 
ProjectHelper.extractNameFromComponentName(elementName);
  +
  +NestedCreator nc = null;
  +if (uri.equals(parentUri)) { //  || uri.equals("")) {
  +nc = (NestedCreator) nestedCreators.get(
  +name.toLowerCase(Locale.US));
  +}
  +if (nc == null) {
  +nc = createAddTypeCreator(project, parent, elementName);
  +}
  +if (nc == null && parent instanceof DynamicConfigurator) {
  +DynamicConfigurator dc = (DynamicConfigurator) parent;
  +final Object nestedElement = 
dc.createDynamicElement(elementName);
  +if (nestedElement != null) {
  +nc = new NestedCreator() {
  +public boolean isPolyMorphic() {
  +return false;
  +}
  +public Class getElementClass() {
  +return null;
  +}
  +
  +public Object getRealObject() {
  +return null;
  +}
  +
  +public Object create(
  +Project project, Object parent, Object ignore) {
  +return nestedElement;
  +}
  +public void store(Object parent, Object child) {
  +}
  +};
  +}
  +}
  +if (nc == null) {
  +throwNotSupported(project, parent, elementName);
  +}
  +return nc;
  +}
  +
   /**
* Creates a named nested element. Depending on the results of the
* initial introspection, either a method in the given parent instance
  @@ -692,6 +738,7 @@
* for an element of a parent.
*
* @param project  Project to which the parent object belongs.
  + * @param parentUriThe namespace uri of the parent object.
* @param parent   Parent object used to create the creator object to
* create and store and instance of a subelement.
* @param elementName  Name of the element to create an instance of.
  @@ -699,8 +746,9 @@
*/
   
   public Creator getElementCreator(
  -Project project, Object parent, String elementName) {
  -NestedCreator nc = getNestedCreator(project, parent, elementName);
  +Project project, String parentUri, Object parent, String 
elementName) {
  +NestedCreator nc = getNestedCreator(
  +project, parentUri, parent, elementName);
   return new Creator(project, parent, nc);
   }
   
  @@ -

Re: [VOTE] macrodef - do attributes as properties or substitution s

[Paul King]

[EMAIL PROTECTED] wrote:
If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
  [ ] as ${x} (look like ant properties)  confusion with 'real'
properties
  [ ] as $(x) to close to A
  [ ] as @x   I miss the brackets
  [ ] as ${attribute:x}   too long
  [X] as @{x} ok, close to A but seeable
different
  [ ] some thing else nothing in my mind to that
Has someone ruled out $${x}? Or does that conflict with
using $$ as some kind of escape sequence for $?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs MacroDefTest.java

[peterreilly]

peterreilly2003/11/18 04:08:01

  Modified:src/main/org/apache/tools/ant/taskdefs MacroDef.java
MacroInstance.java
   src/etc/testcases/taskdefs macrodef.xml
   src/testcases/org/apache/tools/ant/taskdefs
MacroDefTest.java
  Log:
  Do now allow multiple attribute and elements of the same
  name for macrodef.
  
  Revision  ChangesPath
  1.13  +13 -3 ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
  
  Index: MacroDef.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- MacroDef.java 11 Nov 2003 12:01:26 -  1.12
  +++ MacroDef.java 18 Nov 2003 12:08:01 -  1.13
  @@ -78,7 +78,7 @@
   public class MacroDef extends AntlibDefinition  {
   private NestedSequential nestedSequential;
   private String name;
  -private List   attributes = new ArrayList();
  +private Mapattributes = new HashMap();
   private Mapelements = new HashMap();
   
   /**
  @@ -170,7 +170,7 @@
   /**
* @return the nested Attributes
*/
  -public List getAttributes() {
  +public Map getAttributes() {
   return attributes;
   }
   
  @@ -221,7 +221,12 @@
   throw new BuildException(
   "the attribute nested element needed a \"name\" attribute");
   }
  -attributes.add(attribute);
  +if (attributes.get(attribute.getName()) != null) {
  +throw new BuildException(
  +"the attribute " + attribute.getName()
  ++ " has already been specified");
  +}
  +attributes.put(attribute.getName(), attribute);
   }
   
   /**
  @@ -233,6 +238,11 @@
   if (element.getName() == null) {
   throw new BuildException(
   "the element nested element needed a \"name\" attribute");
  +}
  +if (elements.get(element.getName()) != null) {
  +throw new BuildException(
  +"the element " + element.getName()
  ++ " has already been specified");
   }
   elements.put(element.getName(), element);
   }
  
  
  
  1.11  +3 -3  
ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java
  
  Index: MacroInstance.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- MacroInstance.java18 Nov 2003 10:51:41 -  1.10
  +++ MacroInstance.java18 Nov 2003 12:08:01 -  1.11
  @@ -294,9 +294,9 @@
   public void execute() {
   localProperties = new Hashtable();
   Set copyKeys = new HashSet(map.keySet());
  -for (int i = 0; i < macroDef.getAttributes().size(); ++i) {
  -MacroDef.Attribute attribute =
  -(MacroDef.Attribute) macroDef.getAttributes().get(i);
  +for (Iterator i = macroDef.getAttributes().values().iterator();
  + i.hasNext();) {
  +MacroDef.Attribute attribute = (MacroDef.Attribute) i.next();
   String value = (String) map.get(attribute.getName());
   if (value == null) {
   value = attribute.getDefault();
  
  
  
  1.4   +20 -0 ant/src/etc/testcases/taskdefs/macrodef.xml
  
  Index: macrodef.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/macrodef.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- macrodef.xml  23 Sep 2003 13:55:52 -  1.3
  +++ macrodef.xml  18 Nov 2003 12:08:01 -  1.4
  @@ -20,6 +20,26 @@
   
 
   
  +  
  +
  +  
  +  
  +  
  +${text}
  +  
  +
  +  
  +
  +  
  +
  +  
  +  
  +  
  +
  +  
  +
  +  
  +
 
   
 
  
  
  
  1.4   +12 -0 
ant/src/testcases/org/apache/tools/ant/taskdefs/MacroDefTest.java
  
  Index: MacroDefTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/MacroDefTest.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- MacroDefTest.java 23 Sep 2003 13:55:52 -  1.3
  +++ MacroDefTest.java 18 Nov 2003 12:08:01 -  1.4
  @@ -78,6 +78,18 @@
   expectLog("text", "Inner Text");
   }
   
  +public void testDuplicateAttribute() {
  +expectBuildException(
  +"duplicate.attribute",
  +"the attribute text has already been specified");
  +}

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs MacroDefTest.java

[peterreilly]

peterreilly2003/11/18 04:09:32

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
MacroDef.java MacroInstance.java
   src/etc/testcases/taskdefs Tag: ANT_16_BRANCH macrodef.xml
   src/testcases/org/apache/tools/ant/taskdefs Tag:
ANT_16_BRANCH MacroDefTest.java
  Log:
  Sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.7.2.6   +13 -3 ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
  
  Index: MacroDef.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java,v
  retrieving revision 1.7.2.5
  retrieving revision 1.7.2.6
  diff -u -r1.7.2.5 -r1.7.2.6
  --- MacroDef.java 11 Nov 2003 12:02:09 -  1.7.2.5
  +++ MacroDef.java 18 Nov 2003 12:09:31 -  1.7.2.6
  @@ -78,7 +78,7 @@
   public class MacroDef extends AntlibDefinition  {
   private NestedSequential nestedSequential;
   private String name;
  -private List   attributes = new ArrayList();
  +private Mapattributes = new HashMap();
   private Mapelements = new HashMap();
   
   /**
  @@ -170,7 +170,7 @@
   /**
* @return the nested Attributes
*/
  -public List getAttributes() {
  +public Map getAttributes() {
   return attributes;
   }
   
  @@ -221,7 +221,12 @@
   throw new BuildException(
   "the attribute nested element needed a \"name\" attribute");
   }
  -attributes.add(attribute);
  +if (attributes.get(attribute.getName()) != null) {
  +throw new BuildException(
  +"the attribute " + attribute.getName()
  ++ " has already been specified");
  +}
  +attributes.put(attribute.getName(), attribute);
   }
   
   /**
  @@ -233,6 +238,11 @@
   if (element.getName() == null) {
   throw new BuildException(
   "the element nested element needed a \"name\" attribute");
  +}
  +if (elements.get(element.getName()) != null) {
  +throw new BuildException(
  +"the element " + element.getName()
  ++ " has already been specified");
   }
   elements.put(element.getName(), element);
   }
  
  
  
  1.5.2.6   +3 -3  
ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java
  
  Index: MacroInstance.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java,v
  retrieving revision 1.5.2.5
  retrieving revision 1.5.2.6
  diff -u -r1.5.2.5 -r1.5.2.6
  --- MacroInstance.java18 Nov 2003 11:29:07 -  1.5.2.5
  +++ MacroInstance.java18 Nov 2003 12:09:31 -  1.5.2.6
  @@ -294,9 +294,9 @@
   public void execute() {
   localProperties = new Hashtable();
   Set copyKeys = new HashSet(map.keySet());
  -for (int i = 0; i < macroDef.getAttributes().size(); ++i) {
  -MacroDef.Attribute attribute =
  -(MacroDef.Attribute) macroDef.getAttributes().get(i);
  +for (Iterator i = macroDef.getAttributes().values().iterator();
  + i.hasNext();) {
  +MacroDef.Attribute attribute = (MacroDef.Attribute) i.next();
   String value = (String) map.get(attribute.getName());
   if (value == null) {
   value = attribute.getDefault();
  
  
  
  No   revision
  No   revision
  1.2.2.2   +20 -0 ant/src/etc/testcases/taskdefs/macrodef.xml
  
  Index: macrodef.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/macrodef.xml,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- macrodef.xml  23 Sep 2003 13:56:44 -  1.2.2.1
  +++ macrodef.xml  18 Nov 2003 12:09:31 -  1.2.2.2
  @@ -20,6 +20,26 @@
   
 
   
  +  
  +
  +  
  +  
  +  
  +${text}
  +  
  +
  +  
  +
  +  
  +
  +  
  +  
  +  
  +
  +  
  +
  +  
  +
 
   
 
  
  
  
  No   revision
  No   revision
  1.2.2.2   +12 -0 
ant/src/testcases/org/apache/tools/ant/taskdefs/MacroDefTest.java
  
  Index: MacroDefTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/MacroDefTest.java,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- MacroDefTest.java 23 Sep 2003 13:56:44 -  1.2.2.1
  +++ MacroDefTest.java 18 Nov 2003 12:09:32 -  1.2.2.

cvs commit: ant WHATSNEW

[peterreilly]

peterreilly2003/11/18 04:12:01

  Modified:.Tag: ANT_16_BRANCH WHATSNEW
  Log:
  Add namespace change to WHATSNEW
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.503.2.12 +5 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.503.2.11
  retrieving revision 1.503.2.12
  diff -u -r1.503.2.11 -r1.503.2.12
  --- WHATSNEW  6 Nov 2003 21:26:19 -   1.503.2.11
  +++ WHATSNEW  18 Nov 2003 12:12:01 -  1.503.2.12
  @@ -3,6 +3,11 @@
   
   Changes that could break older environments:
   
  +* Changed namespace processing. The namespace uri
  +  of nested elements of a type or a task are now the
  +  same as the type or task. Previously the namespace uri
  +  of nested elements was ant's namespace uri. This change will affect users
  +  of ant 1.6b1 and ant 1.6b2.
   
   Fixed bugs:
   ---
  
  
  

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

RE: [VOTE] macrodef - do attributes as properties or substitution s

[Jan . Materne]

> >>If macrodef attribute are to be implements as substitutions, what
> >>should be the notation? (where x is the attribute name)
> >>
> > 
> >   [ ] as ${x} (look like ant properties)  confusion with 'real'
> > properties
> >   [ ] as $(x) to close to A
> >   [ ] as @x   I miss the brackets
> >   [ ] as ${attribute:x}   too long
> >   [X] as @{x} ok, close to 
> A but seeable
> > different
> >   [ ] some thing else nothing in my 
> mind to that
> 
> Has someone ruled out $${x}? Or does that conflict with
> using $$ as some kind of escape sequence for $?

That´s a part of "some thing else" :-)
But you will confound that with escaping sequence of properties.


Jan

package´s names are diffrent?

[Edson Alves Pereira]

Hello folks, why some or most of ant´s source files have their
package names different from what we see in the terminal output, for
example:

This is JspC.java´s package name:
package org.apache.tools.ant.taskdefs.optional.jsp;

But in my terminal i see this one:
[jasperc] at org.apache.jasper.JspC.execute(JspC.java:769)

Could someone explain how it could be?

Regards,
Edson

Re: package´s names are diffrent?

[Stefan Bodewig]

On Tue, 18 Nov 2003, Edson Alves Pereira
<[EMAIL PROTECTED]> wrote:

>   This is JspC.java´s package name:
>   package org.apache.tools.ant.taskdefs.optional.jsp;
> 
>   But in my terminal i see this one:
>   [jasperc] at org.apache.jasper.JspC.execute(JspC.java:769)
> 
>   Could someone explain how it could be?

Sure.  Ant's JspC invokes jasper's JspC, which is part of Tomcat, BTW.

Stefan

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

RE: package´s names are diffrent?

[Edson Alves Pereira]

But if JspC.java package name is:
org.apache.tools.ant.taskdefs.optional.jsp.JspC, how it could be displayed
like:
> org.apache.jasper.JspC
> 
> --
> De:   Stefan Bodewig[SMTP:[EMAIL PROTECTED]
> Responder:Ant Developers List
> Enviada:  terça-feira, 18 de novembro de 2003 10:42
> Para: [EMAIL PROTECTED]
> Assunto:  Re: package´s names are diffrent?
> 
> On Tue, 18 Nov 2003, Edson Alves Pereira
> <[EMAIL PROTECTED]> wrote:
> 
> > This is JspC.java´s package name:
> > package org.apache.tools.ant.taskdefs.optional.jsp;
> > 
> > But in my terminal i see this one:
> > [jasperc] at org.apache.jasper.JspC.execute(JspC.java:769)
> > 
> > Could someone explain how it could be?
> 
> Sure.  Ant's JspC invokes jasper's JspC, which is part of Tomcat, BTW.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: package´s names are diffrent?

[Stefan Bodewig]

On Tue, 18 Nov 2003, Edson Alves Pereira
<[EMAIL PROTECTED]> wrote:

>   But if JspC.java package name is:
>   org.apache.tools.ant.taskdefs.optional.jsp.JspC, how it
>   could be displayed like:
>> org.apache.jasper.JspC

Because ther also is a class named JspC in the package org.apache.jasper
and the one in Ant's package (indirectly) invokes Jasper's.  You can
find that class in one of Tomcat's CVS modules.

Stefan

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

RE: package´s names are diffrent?

[Edson Alves Pereira]

Now its clear. Thank you.

> --
> De:   Stefan Bodewig[SMTP:[EMAIL PROTECTED]
> Responder:Ant Developers List
> Enviada:  terça-feira, 18 de novembro de 2003 10:53
> Para: [EMAIL PROTECTED]
> Assunto:  Re: package´s names are diffrent?
> 
> On Tue, 18 Nov 2003, Edson Alves Pereira
> <[EMAIL PROTECTED]> wrote:
> 
> > But if JspC.java package name is:
> > org.apache.tools.ant.taskdefs.optional.jsp.JspC, how it
> > could be displayed like:
> >> org.apache.jasper.JspC
> 
> Because ther also is a class named JspC in the package org.apache.jasper
> and the one in Ant's package (indirectly) invokes Jasper's.  You can
> find that class in one of Tomcat's CVS modules.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: Property resolution in a task

[Christopher Lenz]

[EMAIL PROTECTED] wrote:
Ok, that comes from a guy who works more on DOM-Nodes than me (=nothing) :-)
Should we add that to Project class? (If we are allowed to do that)
I don't think there's a need to add this to the Ant core. It's not hard 
to implement (if one is familiar with the DOM ;-) ), and I can't think 
of many use cases for this functionality. If neither the Ant core nor a 
builtin Task requires this functionality, it shouldn't go in. But that's 
just my opinion, and I may very well be missing something ;-)

--
Christopher Lenz
/=/ cmlenz at gmx.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ant 1.6 and namespace

[Christopher Lenz]

peter reilly wrote:
On Monday 17 November 2003 17:20, Dominique Devienne wrote:
Slightly related, if I extracted or wrote a schema for Ant,
and specified an xsi:schemaLocation attribute in ,
will Ant ignore the attribute, or barf?
If the class did not contain a setSchemaLocation() method or
was an instance of DynamicConfigurable it would barf.
Well, Ant should check namespaces on attributes. I'm not sure whether 
you've committed a related change already, but anywhere here's my 
proposal for a simple rule:

If the attribute has no namespace (not to be confused with it being in 
the default namespace), or the namespace URI of the attribute matches 
the namespace URI of the containing element, Ant uses the attribute to 
configure the underlying object (via introspection or 
DynamicConfigurator). Otherwise, the attribute should be ignored (or 
possibly handled specially, like maybe the 'ant-type' attribute).

My original namespace support only allowed "antlib:*" to
be used for typedef's uri attribute (and hence antlib), all
other namespace uri's were ignored - see for example:
http://marc.theaimsgroup.com/?l=ant-dev&m=105336417419712&w=2
Such an artificial limitation does not make sense to me, and also 
doesn't seem to help with the problem at hand, AFAICT. The "antlib:" URI 
scheme has one main feature IIUC, namely the autodiscovery of antlibs 
based on the package name. This feature is orthogonal to the namespace 
URIs used for antlibs manually defined using .

All namespace URIs not actually mapped to an antlib, either by the 
"antlib:" scheme or by an explicit , should be ignored (or 
handled as text -- not sure what the current implementation does). That 
decision should not involve the actual value of the namespace URI though.

We could modify namespace processing to ignore attributes not in the
"right" namespace.
See above.
-chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17973] - A target just like a target

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=17973

A  target just like a  target





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 14:51 ---
If this Bug 24761 is marked as a dup of this bug, then I have a requirement 
that this fix includes a property that is set if a the build has failed prior 
to calling the  target. 
 
--glenn opdycke-hansen

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

RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 18, 2003 2:06 AM
To: [EMAIL PROTECTED]
Subject: RE: macrodef - do attributes as properties or substitutions


> > 
> > 
> > 
> > 
> > 
> 
> I don't think we should need any special cludges just to support this 
> usecase. 8-)
> 
> Give two a completely bogus, impossible to be used in any real world 
> usage value and check for that.  Should be easier than comparing it to 
> a literal ${one} or @one or whathever.
> 
> 
> 
>
> default="nobody-with-a-sane-mind-would-ever-want-to-use-this-value"/>
> 

Nice idea - usually such nice words don´t come into my mind when I´m 
programming :-) But the string comparison would be easier.

Jan

I have used a similar idea with a build file full of "template" targets that 
use a fileset reference.  The reference must be defined globally or the build 
will break, but only some of the users of the file of "templates" actually need 
the reference.  So, since references can be overridden, the solution is, 
similar to Stefan's, 





Later, a user of this buildfile can redefine the globaltlds reference, if it 
needs to, to something real.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

Re: Ant 1.6 and namespace

[peter reilly]

On Tuesday 18 November 2003 14:27, Christopher Lenz wrote:
> peter reilly wrote:
> > On Monday 17 November 2003 17:20, Dominique Devienne wrote:
> >>Slightly related, if I extracted or wrote a schema for Ant,
> >>and specified an xsi:schemaLocation attribute in ,
> >>will Ant ignore the attribute, or barf?
> >
> > If the class did not contain a setSchemaLocation() method or
> > was an instance of DynamicConfigurable it would barf.
>
> Well, Ant should check namespaces on attributes. I'm not sure whether
> you've committed a related change already, but anywhere here's my
> proposal for a simple rule:
>
> If the attribute has no namespace (not to be confused with it being in
> the default namespace), or the namespace URI of the attribute matches
> the namespace URI of the containing element, Ant uses the attribute to
> configure the underlying object (via introspection or
> DynamicConfigurator). Otherwise, the attribute should be ignored (or
> possibly handled specially, like maybe the 'ant-type' attribute).

Yep, this is the way I intended to handle the attributes.

>
> > My original namespace support only allowed "antlib:*" to
> > be used for typedef's uri attribute (and hence antlib), all
> > other namespace uri's were ignored - see for example:
> > http://marc.theaimsgroup.com/?l=ant-dev&m=105336417419712&w=2
>
> Such an artificial limitation does not make sense to me, and also
> doesn't seem to help with the problem at hand, AFAICT. The "antlib:" URI
> scheme has one main feature IIUC, namely the autodiscovery of antlibs
> based on the package name. This feature is orthogonal to the namespace
> URIs used for antlibs manually defined using .
>
> All namespace URIs not actually mapped to an antlib, either by the
> "antlib:" scheme or by an explicit , should be ignored

This is difficult as the the uri attribute of a typedef is handled at
run-time and ns handling is done at parse time, hence my initial
rule.

> (or
> handled as text -- not sure what the current implementation does).

The current implementation will whine.

Peter

> That
> decision should not involve the actual value of the namespace URI though.
>
> > We could modify namespace processing to ignore attributes not in the
> > "right" namespace.
>
> See above.
>
> -chris


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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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  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]

Re: [VOTE] local for 1.6

[peter reilly]

(hopefully this should be the final feature vote for 1.6)

The local feature allows local properties - properties
that are valid only for the enclosing scope.

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

This is a useful feature in general and for macrodef in particular.
For example the macrodef in Stefan's blog:

http://stefanbodewig.blogger.de/20031114

may be implemented by:

  


  
  
  Couldn't find ${class}

  

  
  

Vote:
[ ] local for ant 1.6
[ ] wait for ant 1.7


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

Re: [VOTE] local for 1.6

[Stefan Bodewig]

On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> Vote:
> [X] local for ant 1.6
> [ ] wait for ant 1.7

and done right ;-)

Stefan

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

My itches with (was Re: [VOTE] local for 1.6)

[Stefan Bodewig]

On 18 Nov 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> 
>> Vote:
>> [X] local for ant 1.6
>> [ ] wait for ant 1.7
> 
> and done right ;-)

Things we need to consider IMHO:

(1) Syntax

Your proposal uses a  task that sets up a local scope for a
named property until the enclosing target/sequential finishes.  Jose
Alberto suggested to use a  TaskContainer instead, something
like


  


which would essentially just add an explicit (and differently named)
 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 

Re: My itches with (was Re: [VOTE] local for 1.6)

[peter reilly]

On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> On 18 Nov 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >> Vote:
> >> [X] local for ant 1.6
> >> [ ] wait for ant 1.7
> >
> > and done right ;-)

Ouch ;-)

>
> Things we need to consider IMHO:
>
> (1) Syntax
>
> Your proposal uses a  task that sets up a local scope for a
> named property until the enclosing target/sequential finishes.  Jose
> Alberto suggested to use a  TaskContainer instead, something
> like
>
> 
>   
> 
>
> which would essentially just add an explicit (and differently named)
>  to your proposal.  I think I prefer the more explicit,
> even if more verbose syntax of the second form.

I think that this looks clumsy. Making local's valid for the
current block scope (target level, or sequential level) feels (to
me) more natural. However, I can see benefits ;- my code may not
catch all uses of sequential.

(note as well that local-property is not a valid name, localproperty
would be correct).

> (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.

I think that this will reduce their usefullness a lot. The idea
of not overridding user properties comes from the  family
behaviour, but they can overriden other properties.

>
> (3) Extent of local properties
>
> You make the local properties available to 

Re: My itches with (was Re: [VOTE] local for 1.6)

[peter reilly]

On Tuesday 18 November 2003 15:53, peter reilly wrote:
> me) more natural. However, I can see benefits ;- my code may not
Opps that should of course be "the" code and not "my" code.

Peter


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

RE: [VOTE] macrodef - do attributes as properties or substitution s

[Shatzer, Larry]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] macrodef - do attributes as properties or
> substitutions
> 
> >  [ ] as $(x) 
> >  [ ] as @{x}
> 
> either one works for me - as well as [EMAIL PROTECTED]
> 

What about {$x}? Or is it too close to a typo for a regular property?

-- Larry

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

DO NOT REPLY [Bug 24743] - javadoc task fails for multiple source locations

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24743

javadoc task fails for multiple source locations

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Steve Cohen]

What about {$x}? Or is it too close to a typo for a regular property?

way too confusing, IMHO.  And departs significant from our "pattern"
which seems to be 
identifier type marker, open curly brace, identifier, close curly brace

The more I look at this, the clearer my clear choice becomes for @{x}.
It maintains the ant "pattern" of identifier naming while being quite
significantly different in an important way so that visual confusion
will be unlikely, even when the script writer is tired :-)


-Original Message-
From: Shatzer, Larry [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 18, 2003 10:09 AM
To: 'Ant Developers List'
Subject: RE: [VOTE] macrodef - do attributes as properties or
substitutions


> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> >  [ ] as $(x)
> >  [ ] as @{x}
> 
> either one works for me - as well as [EMAIL PROTECTED]
> 

What about {$x}? Or is it too close to a typo for a regular property?

-- Larry

-
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: My itches with (was Re: [VOTE] local for 1.6)

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >
> > Things we need to consider IMHO:
> >
> > (1) Syntax
> >
> > Your proposal uses a  task that sets up a local scope for a 
> > named property until the enclosing target/sequential 
> finishes.  Jose 
> > Alberto suggested to use a  TaskContainer instead, something 
> > like
> >
> > 
> >   
> > 
> >

Just for the record, my syntax was more like:


  ...


Which does not need inner special elements (less clumsy) but it
requires one nesting per property (but really, how many locals
would you have one after the other?)

> > which would essentially just add an explicit (and 
> differently named) 
> >  to your proposal.  I think I prefer the more explicit, 
> > even if more verbose syntax of the second form.
> 
> I think that this looks clumsy. Making local's valid for the 
> current block scope (target level, or sequential level) feels (to
> me) more natural. However, I can see benefits ;- my code may 
> not catch all uses of sequential.
> 

My major issue with the current implementation proposal is that
it touches way too many places in the code. It needs to change the
implemention of almost all the usages of sequential (and target).
In my design it should only touch  itself and the datastructures
for property handling (given that we want to use threadlocals).

It is a very much less footprint and that I think is good.

> (note as well that local-property is not a valid name, 
> localproperty would be correct).
> 
> > (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.
> 
> I think that this will reduce their usefullness a lot. The 
> idea of not overridding user properties comes from the  
> family behaviour, but they can overriden other properties.
> 

Agreed, if I cannot override properties, what was the point of all this
discussion?
The proposal always allowed to override properties.

> >
> > (3) Extent of local properties
> >
> > You make the local properties available to 

cvs commit: ant/src/main/org/apache/tools/ant/helper ProjectHelper2.java

[peterreilly]

peterreilly2003/11/18 09:06:58

  Modified:src/testcases/org/apache/tools/ant/taskdefs XmlnsTest.java
   src/etc/testcases/taskdefs xmlns.xml
   src/main/org/apache/tools/ant/helper ProjectHelper2.java
  Log:
  Ignore attributes for different uris.
  
  Revision  ChangesPath
  1.3   +8 -0  
ant/src/testcases/org/apache/tools/ant/taskdefs/XmlnsTest.java
  
  Index: XmlnsTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/XmlnsTest.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- XmlnsTest.java13 Aug 2003 13:36:36 -  1.2
  +++ XmlnsTest.java18 Nov 2003 17:06:58 -  1.3
  @@ -88,6 +88,14 @@
   "Attempt to use a reserved URI ant:notallowed");
   }
   
  +public void testOther() {
  +expectLog("other", "a message");
  +}
  +
  +public void testNsAttributes() {
  +expectLog("ns.attributes", "hello world");
  +}
  +
   public static class MyTask extends Task {
   public void execute() {
   log("MyTask called");
  
  
  
  1.3   +12 -1 ant/src/etc/testcases/taskdefs/xmlns.xml
  
  Index: xmlns.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/xmlns.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- xmlns.xml 29 Oct 2003 10:18:13 -  1.2
  +++ xmlns.xml 18 Nov 2003 17:06:58 -  1.3
  @@ -1,5 +1,6 @@
   
  -
  +
   
 
   
  @@ -14,6 +15,16 @@
name="mytask"
uri="this.is.another.test.uri" />
   
  +  
  +
  +  
  +
  +  
  +
  +  
  +
  +
 
   
 
  
  
  
  1.37  +19 -1 
ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java
  
  Index: ProjectHelper2.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- ProjectHelper2.java   18 Nov 2003 10:51:41 -  1.36
  +++ ProjectHelper2.java   18 Nov 2003 17:06:58 -  1.37
  @@ -645,9 +645,15 @@
*/
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String key = attrs.getLocalName(i);
   String value = attrs.getValue(i);
  -
  + 
   if (key.equals("default")) {
   if (value != null && !value.equals("")) {
   if (!context.isIgnoringProjectTag()) {
  @@ -797,6 +803,12 @@
   context.addTarget(target);
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String key = attrs.getLocalName(i);
   String value = attrs.getValue(i);
   
  @@ -967,6 +979,12 @@
   = new RuntimeConfigurable(task, task.getTaskName());
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String name = attrs.getLocalName(i);
   String value = attrs.getValue(i);
   // PR: Hack for ant-type value
  
  
  

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

cvs commit: ant/src/main/org/apache/tools/ant/helper ProjectHelper2.java

[peterreilly]

peterreilly2003/11/18 09:07:24

  Modified:src/testcases/org/apache/tools/ant/taskdefs Tag:
ANT_16_BRANCH XmlnsTest.java
   src/etc/testcases/taskdefs Tag: ANT_16_BRANCH xmlns.xml
   src/main/org/apache/tools/ant/helper Tag: ANT_16_BRANCH
ProjectHelper2.java
  Log:
  Sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.2.2.1   +8 -0  
ant/src/testcases/org/apache/tools/ant/taskdefs/XmlnsTest.java
  
  Index: XmlnsTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/XmlnsTest.java,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- XmlnsTest.java13 Aug 2003 13:36:36 -  1.2
  +++ XmlnsTest.java18 Nov 2003 17:07:24 -  1.2.2.1
  @@ -88,6 +88,14 @@
   "Attempt to use a reserved URI ant:notallowed");
   }
   
  +public void testOther() {
  +expectLog("other", "a message");
  +}
  +
  +public void testNsAttributes() {
  +expectLog("ns.attributes", "hello world");
  +}
  +
   public static class MyTask extends Task {
   public void execute() {
   log("MyTask called");
  
  
  
  No   revision
  No   revision
  1.1.2.2   +12 -1 ant/src/etc/testcases/taskdefs/xmlns.xml
  
  Index: xmlns.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/xmlns.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- xmlns.xml 29 Oct 2003 10:21:13 -  1.1.2.1
  +++ xmlns.xml 18 Nov 2003 17:07:24 -  1.1.2.2
  @@ -1,5 +1,6 @@
   
  -
  +
   
 
   
  @@ -14,6 +15,16 @@
name="mytask"
uri="this.is.another.test.uri" />
   
  +  
  +
  +  
  +
  +  
  +
  +  
  +
  +
 
   
 
  
  
  
  No   revision
  No   revision
  1.33.2.4  +19 -1 
ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java
  
  Index: ProjectHelper2.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
  retrieving revision 1.33.2.3
  retrieving revision 1.33.2.4
  diff -u -r1.33.2.3 -r1.33.2.4
  --- ProjectHelper2.java   18 Nov 2003 11:29:06 -  1.33.2.3
  +++ ProjectHelper2.java   18 Nov 2003 17:07:24 -  1.33.2.4
  @@ -645,9 +645,15 @@
*/
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String key = attrs.getLocalName(i);
   String value = attrs.getValue(i);
  -
  + 
   if (key.equals("default")) {
   if (value != null && !value.equals("")) {
   if (!context.isIgnoringProjectTag()) {
  @@ -797,6 +803,12 @@
   context.addTarget(target);
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String key = attrs.getLocalName(i);
   String value = attrs.getValue(i);
   
  @@ -967,6 +979,12 @@
   = new RuntimeConfigurable(task, task.getTaskName());
   
   for (int i = 0; i < attrs.getLength(); i++) {
  +String attrUri = attrs.getURI(i);
  +if (attrUri != null
  +&& !attrUri.equals("")
  +&& !attrUri.equals(uri)) {
  +continue; // Ignore attributes from unknown uris
  +}
   String name = attrs.getLocalName(i);
   String value = attrs.getValue(i);
   // PR: Hack for ant-type value
  
  
  

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

cvs commit: ant WHATSNEW

[peterreilly]

peterreilly2003/11/18 09:16:29

  Modified:.Tag: ANT_16_BRANCH WHATSNEW
  Log:
  note attribute support change
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.503.2.13 +2 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.503.2.12
  retrieving revision 1.503.2.13
  diff -u -r1.503.2.12 -r1.503.2.13
  --- WHATSNEW  18 Nov 2003 12:12:01 -  1.503.2.12
  +++ WHATSNEW  18 Nov 2003 17:16:28 -  1.503.2.13
  @@ -80,6 +80,8 @@
   
   * provide stack for errors using import, ant, antcall, subant and macros
   
  +* ignore attributes from different URIS
  +
   Changes from Ant 1.6.B1 to Ant 1.6.B2
   =
   
  
  
  

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

Re: My itches with (was Re: [VOTE] local for 1.6)

[peter reilly]

On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> > > Things we need to consider IMHO:
> > >
> > > (1) Syntax
> > >
> > > Your proposal uses a  task that sets up a local scope for a
> > > named property until the enclosing target/sequential
> >
> > finishes.  Jose
> >
> > > Alberto suggested to use a  TaskContainer instead, something
> > > like
> > >
> > > 
> > >   
> > > 
>
> Just for the record, my syntax was more like:
>
> 
>   ...
> 
>
> Which does not need inner special elements (less clumsy) but it
> requires one nesting per property (but really, how many locals
> would you have one after the other?)
>
> > > which would essentially just add an explicit (and
> >
> > differently named)
> >
> > >  to your proposal.  I think I prefer the more explicit,
> > > even if more verbose syntax of the second form.
> >
> > I think that this looks clumsy. Making local's valid for the
> > current block scope (target level, or sequential level) feels (to
> > me) more natural. However, I can see benefits ;- my code may
> > not catch all uses of sequential.
>
> My major issue with the current implementation proposal is that
> it touches way too many places in the code. It needs to change the
> implemention of almost all the usages of sequential (and target).

This is not quite true. It does change the implementation of
target and task but usage of these should not need to change.
For example ant-contrib has a  task with a 
element. This works correctly as a local block without any changes to the
implementation of Outofdate:

  


  
  
  

l is '${l}'
  

  

prints out "l in 'in outofdate'".


> In my design it should only touch  itself and the datastructures
> for property handling (given that we want to use threadlocals).
>
> It is a very much less footprint and that I think is good.
>
> > (note as well that local-property is not a valid name,
> > localproperty would be correct).
> >
> > > (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.
> >
> > I think that this will reduce their usefullness a lot. The
> > idea of not overridding user properties comes from the 
> > family behaviour, but they can overriden other properties.
>
> Agreed, if I cannot override properties, what was the point of all this
> discussion?
> The proposal always allowed to override properties.
>
> > > (3) Extent of local properties
> > >
> > > You make the local properties available to 

cvs commit: ant/docs/manual/CoreTasks sql.html

[peterreilly]

peterreilly2003/11/18 09:37:44

  Modified:docs/manual/CoreTasks sql.html
  Log:
  remove hanging "the" in sql manual page
  PR: 24419
  Obtained from: Matthew Cary
  
  Revision  ChangesPath
  1.21  +0 -3  ant/docs/manual/CoreTasks/sql.html
  
  Index: sql.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/sql.html,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- sql.html  9 Apr 2003 13:15:31 -   1.20
  +++ sql.html  18 Nov 2003 17:37:44 -  1.21
  @@ -180,9 +180,6 @@
   Sql's classpath attribute is a PATH like structure and can also be set via a 
nested
   classpath element. It is used to load the JDBC classes.
  -
  -The 
  -
   
   Examples
   

cvs commit: ant/docs/manual/CoreTasks sql.html

[peterreilly]

peterreilly2003/11/18 09:38:26

  Modified:docs/manual/CoreTasks Tag: ANT_16_BRANCH sql.html
  Log:
  Sync with head
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.20.2.2  +0 -3  ant/docs/manual/CoreTasks/sql.html
  
  Index: sql.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/sql.html,v
  retrieving revision 1.20.2.1
  retrieving revision 1.20.2.2
  diff -u -r1.20.2.1 -r1.20.2.2
  --- sql.html  9 Oct 2003 21:01:06 -   1.20.2.1
  +++ sql.html  18 Nov 2003 17:38:26 -  1.20.2.2
  @@ -181,9 +181,6 @@
   Sql's classpath attribute is a PATH like structure and can also be set via a 
nested
   classpath element. It is used to load the JDBC classes.
  -
  -The 
  -
   
   Examples
   

DO NOT REPLY [Bug 24419] - Truncated documentation for sql Task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24419

Truncated documentation for sql Task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 17:39 ---
Fixed in cvs head and 1.6 head
Thanks.

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

DO NOT REPLY [Bug 24673] - On Netscape (7), Ant task list is empty

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24673

On Netscape (7), Ant task list is empty

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 17:41 ---
Changing this to "WORKSFORME"

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

DO NOT REPLY [Bug 24296] - "import" fails to find absolute files without drive specifier (windows only)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24296

"import" fails to find absolute files without drive specifier (windows only)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 17:44 ---
This should be fixed in current ant cvs 1.6 branch head

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

DO NOT REPLY [Bug 24685] - Copy task does not deal with filterfile correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24685

Copy task does not deal with filterfile correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 17:57 ---
I have just tested this and the filterfile works
for me.
Is there anymore inforamtion ? - the config-file for
example.

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

RE: My itches with (was Re: [VOTE] local for 1.6)

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> >
> > My major issue with the current implementation proposal is that it 
> > touches way too many places in the code. It needs to change the 
> > implemention of almost all the usages of sequential (and target).
> 
> This is not quite true. It does change the implementation of 
> target and task but usage of these should not need to change. 
> For example ant-contrib has a  task with a 
>  element. This works correctly as a local block 
> without any changes to the implementation of Outofdate:
> 
>   
> 
> 
>   
>   
>   
> 
> l is '${l}'
>   
> 
>   
> 
> prints out "l in 'in outofdate'".
> 

Would it work if my task extends Sequential? 
How about if my task just implements TaskContainer interface?

By having just a regular task that controls the feature there
is less room for confusion between which tasks do provide
access to the feature and which do not.

For example, what is the effect of having something like this:
Assume I have a task that accepts as an element a task. It does not
uses sequential, just gets the task element and executes it.

What happens if I pass a  declaration as the element?
What would be the lifetime of the property being defined?
Can we make sure the span is just the execution of the  itself?
What if I just create a  task using script? Can I violate
the scoping rules by doing things like that?

With the ... version, there are no issues, because the
scope is syntactically defined by the task itself.

Hope this is compelling enough.


Jose Alberto
> 

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

DO NOT REPLY [Bug 23941] - move task deletes source directory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=23941

move task deletes source directory

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 18:20 ---
I can confirm that this problem exists in ant1.5.
It has been fixed in ant 1.6

*** This bug has been marked as a duplicate of 18886 ***

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

DO NOT REPLY [Bug 18886] - Move files deletes directory if the directory is empty

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=18886

Move files deletes directory if the directory is empty

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 18:20 ---
*** Bug 23941 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 24685] - Copy task does not deal with filterfile correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24685

Copy task does not deal with filterfile correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 18:23 ---
Reviewed the config files and the it appears as though there was actually a
configuration error. The issue was to do with the fact that there was email
addresses in the properties files (containing @ symbols), which was causing the
default filter tokens to be confused. 

Example:
...
[EMAIL PROTECTED]@
email.change.confirmation.body=Your address has been modified. Please contact
[EMAIL PROTECTED] for further information.
[EMAIL PROTECTED]@
...

The error given in verbose output using ANT 1.6beta was:
"Infinite loop in tokens"
And this was causing no replacements to be made from the filtersfile.

Suprisingly, ANT 1.5.4 seemed to be able to deal with this issue, however you
can happily mark this as not a bug since changing the filter end/begin tokens
fixed the problem.

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

Re: My itches with (was Re: [VOTE] local for 1.6)

[peter reilly]

On Tuesday 18 November 2003 18:14, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> > > My major issue with the current implementation proposal is that it
> > > touches way too many places in the code. It needs to change the
> > > implemention of almost all the usages of sequential (and target).
> >
> > This is not quite true. It does change the implementation of
> > target and task but usage of these should not need to change.
> > For example ant-contrib has a  task with a
> >  element. This works correctly as a local block
> > without any changes to the implementation of Outofdate:
> >
> >   
> > 
> > 
> >   
> >   
> >   
> > 
> > l is '${l}'
> >   
> > 
> >   
> >
> > prints out "l in 'in outofdate'".
>
> Would it work if my task extends Sequential?
> How about if my task just implements TaskContainer interface?
Yes.
>
> By having just a regular task that controls the feature there
> is less room for confusion between which tasks do provide
> access to the feature and which do not.
True.
>
> For example, what is the effect of having something like this:
> Assume I have a task that accepts as an element a task. It does not
> uses sequential, just gets the task element and executes it.
I this case it would need to be a TaskContainer.
> What happens if I pass a  declaration as the element?
> What would be the lifetime of the property being defined?
The lifetime of the container.
> Can we make sure the span is just the execution of the  itself?
> What if I just create a  task using script? Can I violate
> the scoping rules by doing things like that?

In all cases, the local will exist for the span of the containing
container. With script one can do all sorts of silly things

>
> With the ... version, there are no issues, because the
> scope is syntactically defined by the task itself.
>
> Hope this is compelling enough.

Cheers,
Peter


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

DO NOT REPLY [Bug 24685] - Copy task does not deal with filterfile correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24685

Copy task does not deal with filterfile correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 18:33 ---
Thanks for the feedback.
It looks that that message should be a WARNING level?

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

Re: [VOTE] local for 1.6

[Steve Loughran]

peter reilly wrote:
(hopefully this should be the final feature vote for 1.6)
The local feature allows local properties - properties
that are valid only for the enclosing scope.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942
This is a useful feature in general and for macrodef in particular.
For example the macrodef in Stefan's blog:
http://stefanbodewig.blogger.de/20031114
may be implemented by:
  


  
  
  Couldn't find ${class}

  
  
  
Vote:
[ -0] local for ant 1.6
[ +0] wait for ant 1.7
It would seem better to get this right before we ship, as then things 
stay broken. Holding stuff over to 1.7 lets us experiment with the model 
more before we actually ship. But I agree, without it, macrodef is more 
limited.

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

DO NOT REPLY [Bug 24798] New: - BZip2: faster, less memory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24798

BZip2: faster, less memory

   Summary: BZip2: faster, less memory
   Product: Ant
   Version: 1.7Alpha (nightly)
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a patch here to speed up the BZip2 task (50-90%). At the same time this 
patch achieves lower memory usage (35%). 
It's well tested. 
 
Please note this is the first time I'm trying to contribute a patch to 
apache...hoping I can create an attachment on the next page. 
If not, I will send the patch to Keiron Liddle ([EMAIL PROTECTED]), the 
author of the current version.

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

DO NOT REPLY [Bug 24798] - BZip2: faster, less memory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24798

BZip2: faster, less memory





--- Additional Comments From [EMAIL PROTECTED]  2003-11-18 21:15 ---
Created an attachment (id=9184)
Patch for package org.apache.tools.bzip2 to enhance performance

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

DO NOT REPLY [Bug 24799] New: - junitreport stylesheet causes StackOverflow with big replacements

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24799

junitreport stylesheet causes StackOverflow with big replacements

   Summary: junitreport stylesheet causes StackOverflow with big
replacements
   Product: Ant
   Version: 1.5.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have several unit tests that set enormous java.class.path environment
variables.  On Windows machines, the XSL stylesheets for junitreport run this 
block:


\\




This causes a very deep recursion, which even a -Xss12m can't handle.

My current work-around for the JS-escape template replaces the above condition 
with:









\\






Which, though isn't a perfect translation, works.

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

DO NOT REPLY [Bug 24802] New: - The style task and nested classpath

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=24802

The style task and nested classpath

   Summary: The style task and nested classpath
   Product: Ant
   Version: 1.5.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Many Java-based XSLT engines (for example Xalan) support
XSLT extensions implemented in Java.

When such functionality is being used, most of the engines try
to use context class loader to locate the class specified inside
a stylesheet.

However, this fails to resolve when the transformation is launched
from the style task, since it doesn't set the context class loader.

It would be nice if the style task uses the specified nested s
to set the context class loader before it invokes the transformation.

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