DO NOT REPLY [Bug 29045] New: - Updates to Move & Copy

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29045

Updates to Move & Copy

   Summary: Updates to Move & Copy
   Product: Ant
   Version: 1.6.1
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There should be a update to move & copy build in task. This is to report 
errors in a similar way to the exec task.

http://ant.apache.org/manual/CoreTasks/exec.html

In the exec task you can assign the error to an error property and let the 
build continue. But in the case of copy & move it logs the error and 
continues. 

What i would love in ant would be the error reporting for  &  to 
work in the same way as the  task.

regards
Paul

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

RE: Integrated a new task

[Jose Alberto Fernandez]

Yves, This question is for the user-list.

In an case, there is no need for you to rebuild anything,
youshould take a look at ,  and/or
 tasks, which explain how to integrate your code
with ant's.

Cheers,

Jose Alberto
PS: If you have further questions go to the user-list.

> -Original Message-
> From: Le Rumeur Yves [mailto:[EMAIL PROTECTED] 
> Sent: 17 May 2004 17:24
> To: Mailling List Dev Ant
> Subject: Integrated a new task
> 
> 
> 
> Hi,
> 
>   I make a small task for ant, and i want to integrated 
> to my ant just for see. I try to modify the 
> defaults.properties containing the definition of the task in 
> bin/org/apache/tools/ant/taskdefs, ant i need a new types so 
> i make the same step in the second defaults.properties in 
> bin/org/apache/tools/ant/types.
>   After this i recompile all the source of ant but, when 
> i run my ant binaries file, my new task and type ar not 
> integrated (althought i add a needed jar file in the lib of ant.)
>   So i forgot something to integrate totally a new task ot type?
> 
> 
> Thanks
> 
> -- 
> Yves
> 
> 
> -
> 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]

Integrated a new task

[Le Rumeur Yves]

Hi,

I make a small task for ant, and i want to integrated to my ant just
for see. I try to modify the defaults.properties containing the
definition of the task in bin/org/apache/tools/ant/taskdefs, ant i need
a new types so i make the same step in the second defaults.properties in
bin/org/apache/tools/ant/types.
After this i recompile all the source of ant but, when i run my ant
binaries file, my new task and type ar not integrated (althought i add a
needed jar file in the lib of ant.)
So i forgot something to integrate totally a new task ot type?


Thanks

-- 
Yves


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

DO NOT REPLY [Bug 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 14:44 ---
Tell ya what you do... use Ant CVS HEAD with nested s along with  and you should be all set.  The multi-result 
 will be in the next release (probably 1.6.2).

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

DO NOT REPLY [Bug 28993] - [PATCH] Using can break XmlLogger

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28993

[PATCH] Using  can break XmlLogger





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 14:18 ---
The similar is used by the code to check if the definition
is already present (content equals).

The hashcode/equals is used by the logging code to find the
the macrodef object instance in a stack of tasks.

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

DO NOT REPLY [Bug 28993] - [PATCH] Using can break XmlLogger

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28993

[PATCH] Using  can break XmlLogger





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 14:06 ---
I didn't understand the fix Peter :-( It looks like you removed the hashCode 
and equals methods completely, and instead renamed equals() to similar(), but 
the map won't be using similar(), so I don't get it. Do you want to use the 
Object equals/hashCode, and really use object identity (pseudo-pointer) for 
equality (thus emulate using a JDK 1.4 IdentityHashMap?) Thanks, --DD

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

RE: antlibs and classloaders #2

[Jose Alberto Fernandez]

> From: Peter Reilly [mailto:[EMAIL PROTECTED] 
> 
> Jose Alberto Fernandez wrote:
> 
> >>From: Peter Reilly [mailto:[EMAIL PROTECTED]
> >>
> >>In this case the parent is the antlib classloader (it is the default
> >>classloader).
> >>
> >>
> >>
> >
> >So what happens if the toplevel antlib gets loaded from a different 
> >classloader (because I defined classpaths and such). Would the 
> > inside pick-up that as the classloader? Or would 
> it pickup 
> >some default one?
> >
> >  
> >
> Currently it would use the default ant classloader.
> 
That, to me, is wrong. While inside an antlib, you are in the context
of that antlib and hence you need to have access to all classes defined
by it.

> >>>I do not see why that should cause an infinite recursion.
> >>> 
> >>>
> >>>  
> >>>
> >>The problem is that the  >>resource="net/.../antlib.xml">  >>path="cpptasks.jar"/>  in the antlib will pick up 
> >>the antlib.xml resoure that contains  >>resource="net/.../antlib.xml">
> >>task which will pick up .,
> >>
> >>This does not happen with the current ant code, as the  >>resource="net/.../antlib.xml">
> >>  
> >>task will not see the antlib.xml resource in the parent classloader.
> >>
> >>Another way to work-around this is for the typedef to use a thread
> >>specific stack to check
> >>for recursive loading of xml resources.
> >>This probally should be done in any case:
> >>
> >>recursive.xml
> >>
> >>
> >>   
> >>
> >>
> >>build.xml:
> >>
> >>  
> >>
> >>
> >>
> >>
> >
> >What is the difference between this and what we do for 
> s. In 
> >both cases we need to make sure we do not go into an 
> infinite loop. It 
> >should not matter whether the XML is an import fragment or an 
> >antlib.xml
> >  
> >
> Yes, that that the point!.
> 
> A warning should be issued and the antlib should not be loaded again.
> 

Agreed.

Jose Alberto

> Peter
> 
> 
> -
> 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: antlibs and classloaders #2

[Jose Alberto Fernandez]

Mariano,

I also agree with you and what you are saying. However I think
we have several different parts of the proposal that are too loose
and hence allow to break this general concept as you put it.

For example we have:

1) The jars containing the antlig code (which is defined by a classpath
or classloader)

2) The URI for the antlib, which can be specified implicitely with an
antlib:uri or
explicitly with the uri parameter of typedef. Using typedef, you can
load several
antlibs to the same namespace and such.

3) antlib.xml file or resource which contains the XML definitions of the
tasks and types.

Now, all this things can be used in a systemetic way to achieve your
goals (I think),
but they can be used to act in a quite different way and bringing all
kinds of problems.

So, are our objectives just the suggested user patterns for ANTLIBs or
are they
mandatory behaviour of antlibs. Depending on what we want, it will
change the way we
teach people how to write effective reusable antlibs. As oppose to "only
will work on my machine"
kind of antlibs.

This is what I do not think we have a clear understanding. How are
people to use all this moving
parts in a consistent way that promotes reusability, etc, etc.

Jose Alberto

> -Original Message-
> From: Mariano Benitez [mailto:[EMAIL PROTECTED] 
> Sent: 17 May 2004 13:29
> To: Ant Developers List
> Subject: Re: antlibs and classloaders #2
> 
> 
> 
> >This things sound like we are using the wrong abstraction here. 
> > inside an  should use the antlib 
> classloader as the 
> >parent for any subsequent classloader.
> >
> >I do not see why that should cause an infinite recursion.
> >
> >I feel like we have a conceptual mismatch between antlib 
> "the jar" with 
> >the code, and antlib "the resource with the XML definitions". We are 
> >not treating them in a symetric way or as a unit. And hence 
> we are get 
> >into all this conflicting behaviour.
> >  
> >
> 
> I would like to pick from here and try to describe my 
> understanding of 
> the concepts.
> 
> Antlib: I see this as a a definition of tasks within a namespace that 
> involves all the jars required to resolve the execution of 
> the tasks. To 
> put it plainly, I see it as the antlib.xml with a classpath.
> So for me that defines completely the antlib and the 
> extra classpath 
> should be added to the antlib classpath.
> 
> Also, for me is accidental that the antlibs should be 
> located in the 
> $ANT_HOME/lib or in a -lib , actually the antlib 
> definition should 
> start from the antlib.xml, wherever it is, and then create a 
> classloader 
> based on the antlib definition.
> 
> For the special case were the antlib jars are located in the base 
> ant classpath ($ANT_HOME/lib or -lib ) I would not 
> allow adding a 
> classpath since the antlib should be completely contained within the 
> base ant classpath, only when the antlib jars are outside I 
> would allow 
> defining an extra classpath.
> 
> Also, defining antlibs in either way (being inside base ant 
> classpath or outside) should behave the same way, they should be 
> idempotent, meaning that once they are defined, they should not be 
> overriden, I understand that it is not wise to use the same uri for 
> different antlibs, the user should always try to pick unique 
> names for 
> the antlibs, otherwise we go back to a single namespace.
> 
> This is my understanding of antlibs, it is probably out of synch with 
> what you envision on this, but I wanted to let you know what 
> I thought 
> antlibs were about.
> 
> My 2 cents.
> MAriano
> 
> -
> 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 28993] - [PATCH] Using can break XmlLogger

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28993

[PATCH] Using  can break XmlLogger

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 13:59 ---
Thanks

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

DO NOT REPLY [Bug 28993] - [PATCH] Using can break XmlLogger

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28993

[PATCH] Using  can break XmlLogger

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 13:58 ---
The problem was that the macrodef object was placed
in a map before it was fully constructed. Fixed
by changing the "equals" to a "similar" (same
problem occured in UnknownElement).

Also applied changes to XMLlogger and DOMElementWriter.

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

Re: antlibs and classloaders #2

[Peter Reilly]

Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED] 

Jose Alberto Fernandez wrote:
   

This things sound like we are using the wrong abstraction here. 
 inside an  should use the antlib 
 

classloader as the 
   

parent for any subsequent classloader.
 

In this case the parent is the antlib classloader (it is the default 
classloader).

   

So what happens if the toplevel antlib gets loaded from a different
classloader (because I defined classpaths and such). Would the

inside pick-up that as the classloader? Or would it pickup some default
one?
 

Currently it would use the default ant classloader.
I do not see why that should cause an infinite recursion.
 

The problem is that thein the antlib will pick up 
the antlib.xml resoure that contains 
task which will pick up .,

This does not happen with the current ant code, as the 
 
task will not see the antlib.xml resource in the parent classloader.

Another way to work-around this is for the typedef to use a thread 
specific stack to check
for recursive loading of xml resources.
This probally should be done in any case:

recursive.xml

  

build.xml:

 

   

What is the difference between this and what we do for s.
In both cases we need to make sure we do not go into an infinite loop.
It should not matter whether the XML is an import fragment or an
antlib.xml
 

Yes, that that the point!.
A warning should be issued and the antlib should not be loaded again.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/util DOMElementWriter.java

[peterreilly]

peterreilly2004/05/17 06:43:53

  Modified:src/main/org/apache/tools/ant Tag: ANT_16_BRANCH
XmlLogger.java
   src/main/org/apache/tools/ant/util Tag: ANT_16_BRANCH
DOMElementWriter.java
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.39.2.6  +14 -5 ant/src/main/org/apache/tools/ant/XmlLogger.java
  
  Index: XmlLogger.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/XmlLogger.java,v
  retrieving revision 1.39.2.5
  retrieving revision 1.39.2.6
  diff -u -r1.39.2.5 -r1.39.2.6
  --- XmlLogger.java9 Mar 2004 17:01:30 -   1.39.2.5
  +++ XmlLogger.java17 May 2004 13:43:52 -  1.39.2.6
  @@ -116,6 +116,9 @@
   private long startTime;
   /** Element created at the start time. */
   private Element element;
  +public String toString() {
  +return element.getTagName() + ":" + element.getAttribute("name");
  +}
   }
   
   /**
  @@ -178,7 +181,7 @@
   stream = new FileOutputStream(outFilename);
   }
   out = new OutputStreamWriter(stream, "UTF8");
  -out.write("\n");
  +out.write("\n");
   if (xslUri.length() > 0) {
   out.write("\n\n");
  @@ -209,6 +212,10 @@
   threadStack = new Stack();
   threadStacks.put(Thread.currentThread(), threadStack);
   }
  +/* For debugging purposes uncomment:
  +org.w3c.dom.Comment s = doc.createComment("stack=" + threadStack);
  +buildElement.element.appendChild(s);
  + */
   return threadStack;
   }
   
  @@ -252,9 +259,9 @@
   TimedElement poppedStack = (TimedElement) threadStack.pop();
   if (poppedStack != targetElement) {
   throw new RuntimeException("Mismatch - popped element = "
  -+ poppedStack.element
  ++ poppedStack
   + " finished target element = "
  -+ targetElement.element);
  ++ targetElement);
   }
   if (!threadStack.empty()) {
   parentElement = (TimedElement) threadStack.peek();
  @@ -320,11 +327,13 @@
   TimedElement poppedStack = (TimedElement) threadStack.pop();
   if (poppedStack != taskElement) {
   throw new RuntimeException("Mismatch - popped element = "
  -+ poppedStack.element + " finished task element 
= "
  -+ taskElement.element);
  ++ poppedStack + " finished task element = "
  ++ taskElement);
   }
   }
   tasks.remove(task);
  +} else {
  +throw new RuntimeException("Unknown task " + task + " not in " + 
tasks);
   }
   }
   
  
  
  
  No   revision
  No   revision
  1.20.2.5  +6 -0  
ant/src/main/org/apache/tools/ant/util/DOMElementWriter.java
  
  Index: DOMElementWriter.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/util/DOMElementWriter.java,v
  retrieving revision 1.20.2.4
  retrieving revision 1.20.2.5
  diff -u -r1.20.2.4 -r1.20.2.5
  --- DOMElementWriter.java 9 Mar 2004 17:01:57 -   1.20.2.4
  +++ DOMElementWriter.java 17 May 2004 13:43:53 -  1.20.2.5
  @@ -117,6 +117,12 @@
   out.write(encode(child.getNodeValue()));
   break;
   
  +case Node.COMMENT_NODE:
  +out.write("");
  +break;
  +
   case Node.CDATA_SECTION_NODE:
   out.write("

cvs commit: ant/src/main/org/apache/tools/ant/util DOMElementWriter.java

[peterreilly]

peterreilly2004/05/17 06:43:32

  Modified:src/main/org/apache/tools/ant XmlLogger.java
   src/main/org/apache/tools/ant/util DOMElementWriter.java
  Log:
  better diagnostics from XmlLogger.java
  PR: 28993
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.45  +14 -5 ant/src/main/org/apache/tools/ant/XmlLogger.java
  
  Index: XmlLogger.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/XmlLogger.java,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- XmlLogger.java9 Mar 2004 16:47:59 -   1.44
  +++ XmlLogger.java17 May 2004 13:43:32 -  1.45
  @@ -116,6 +116,9 @@
   private long startTime;
   /** Element created at the start time. */
   private Element element;
  +public String toString() {
  +return element.getTagName() + ":" + element.getAttribute("name");
  +}
   }
   
   /**
  @@ -178,7 +181,7 @@
   stream = new FileOutputStream(outFilename);
   }
   out = new OutputStreamWriter(stream, "UTF8");
  -out.write("\n");
  +out.write("\n");
   if (xslUri.length() > 0) {
   out.write("\n\n");
  @@ -209,6 +212,10 @@
   threadStack = new Stack();
   threadStacks.put(Thread.currentThread(), threadStack);
   }
  +/* For debugging purposes uncomment:
  +org.w3c.dom.Comment s = doc.createComment("stack=" + threadStack);
  +buildElement.element.appendChild(s);
  + */
   return threadStack;
   }
   
  @@ -252,9 +259,9 @@
   TimedElement poppedStack = (TimedElement) threadStack.pop();
   if (poppedStack != targetElement) {
   throw new RuntimeException("Mismatch - popped element = "
  -+ poppedStack.element
  ++ poppedStack
   + " finished target element = "
  -+ targetElement.element);
  ++ targetElement);
   }
   if (!threadStack.empty()) {
   parentElement = (TimedElement) threadStack.peek();
  @@ -320,11 +327,13 @@
   TimedElement poppedStack = (TimedElement) threadStack.pop();
   if (poppedStack != taskElement) {
   throw new RuntimeException("Mismatch - popped element = "
  -+ poppedStack.element + " finished task element 
= "
  -+ taskElement.element);
  ++ poppedStack + " finished task element = "
  ++ taskElement);
   }
   }
   tasks.remove(task);
  +} else {
  +throw new RuntimeException("Unknown task " + task + " not in " + 
tasks);
   }
   }
   
  
  
  
  1.25  +6 -0  
ant/src/main/org/apache/tools/ant/util/DOMElementWriter.java
  
  Index: DOMElementWriter.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/util/DOMElementWriter.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- DOMElementWriter.java 9 Mar 2004 16:48:51 -   1.24
  +++ DOMElementWriter.java 17 May 2004 13:43:32 -  1.25
  @@ -117,6 +117,12 @@
   out.write(encode(child.getNodeValue()));
   break;
   
  +case Node.COMMENT_NODE:
  +out.write("");
  +break;
  +
   case Node.CDATA_SECTION_NODE:
   out.write("

RE: antlibs and classloaders #2

[Jose Alberto Fernandez]

> From: Peter Reilly [mailto:[EMAIL PROTECTED] 
> 
> Jose Alberto Fernandez wrote:
> 
> >This things sound like we are using the wrong abstraction here. 
> > inside an  should use the antlib 
> classloader as the 
> >parent for any subsequent classloader.
> >  
> >
> In this case the parent is the antlib classloader (it is the default 
> classloader).
> 

So what happens if the toplevel antlib gets loaded from a different
classloader (because I defined classpaths and such). Would the

inside pick-up that as the classloader? Or would it pickup some default
one?

> >I do not see why that should cause an infinite recursion.
> >  
> >
> The problem is that the  resource="net/.../antlib.xml">  path="cpptasks.jar"/>  in the antlib will pick up 
> the antlib.xml resoure that contains  resource="net/.../antlib.xml">
> task which will pick up .,
> 
> This does not happen with the current ant code, as the  resource="net/.../antlib.xml">
>   
> task will not see the antlib.xml resource in the parent classloader.
> 
> Another way to work-around this is for the typedef to use a thread 
> specific stack to check
> for recursive loading of xml resources.
> This probally should be done in any case:
> 
> recursive.xml
> 
> 
>
> 
> 
> build.xml:
> 
>   
> 
> 

What is the difference between this and what we do for s.
In both cases we need to make sure we do not go into an infinite loop.
It should not matter whether the XML is an import fragment or an
antlib.xml

Jose Alberto
> 
> Peter
> 
> 
> -
> 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]

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

[peterreilly]

peterreilly2004/05/17 06:30:52

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
MacroDef.java
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.7.2.18  +8 -15 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.17
  retrieving revision 1.7.2.18
  diff -u -r1.7.2.17 -r1.7.2.18
  --- MacroDef.java 9 Mar 2004 17:01:33 -   1.7.2.17
  +++ MacroDef.java 17 May 2004 13:30:51 -  1.7.2.18
  @@ -596,13 +596,17 @@
   }
   
   /**
  - * equality method for macrodef, ignores project and
  + * similar equality method for macrodef, ignores project and
* runtime info.
*
* @param obj an Object value
* @return a boolean value
*/
  -public boolean equals(Object obj) {
  +public boolean similar(Object obj) {
  +if (obj == this) {
  +return true;
  +}
  +
   if (obj == null) {
   return false;
   }
  @@ -650,17 +654,6 @@
   }
   
   /**
  - * @return a hash code value for this object.
  - */
  -public int hashCode() {
  -return objectHashCode(name)
  -+ objectHashCode(getURI())
  -+ objectHashCode(nestedSequential)
  -+ objectHashCode(attributes)
  -+ objectHashCode(elements);
  -}
  -
  -/**
* extends AntTypeDefinition, on create
* of the object, the template macro definition
* is given.
  @@ -704,7 +697,7 @@
   return false;
   }
   MyAntTypeDefinition otherDef = (MyAntTypeDefinition) other;
  -return macroDef.equals(otherDef.macroDef);
  +return macroDef.similar(otherDef.macroDef);
   }
   
   /**
  @@ -720,7 +713,7 @@
   return false;
   }
   MyAntTypeDefinition otherDef = (MyAntTypeDefinition) other;
  -return macroDef.equals(otherDef.macroDef);
  +return macroDef.similar(otherDef.macroDef);
   }
   }
   
  
  
  

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

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

[peterreilly]

peterreilly2004/05/17 06:30:17

  Modified:src/main/org/apache/tools/ant/taskdefs MacroDef.java
  Log:
  Fix use of hashcode in MacroDef
  Logger code uses the macrodef as a key in a map before it is fully
  configured so the hashcode had changed while the object was
  in the map
  PR: 28993
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.25  +8 -15 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.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- MacroDef.java 9 Mar 2004 16:48:06 -   1.24
  +++ MacroDef.java 17 May 2004 13:30:17 -  1.25
  @@ -596,13 +596,17 @@
   }
   
   /**
  - * equality method for macrodef, ignores project and
  + * similar equality method for macrodef, ignores project and
* runtime info.
*
* @param obj an Object value
* @return a boolean value
*/
  -public boolean equals(Object obj) {
  +public boolean similar(Object obj) {
  +if (obj == this) {
  +return true;
  +}
  +
   if (obj == null) {
   return false;
   }
  @@ -650,17 +654,6 @@
   }
   
   /**
  - * @return a hash code value for this object.
  - */
  -public int hashCode() {
  -return objectHashCode(name)
  -+ objectHashCode(getURI())
  -+ objectHashCode(nestedSequential)
  -+ objectHashCode(attributes)
  -+ objectHashCode(elements);
  -}
  -
  -/**
* extends AntTypeDefinition, on create
* of the object, the template macro definition
* is given.
  @@ -704,7 +697,7 @@
   return false;
   }
   MyAntTypeDefinition otherDef = (MyAntTypeDefinition) other;
  -return macroDef.equals(otherDef.macroDef);
  +return macroDef.similar(otherDef.macroDef);
   }
   
   /**
  @@ -720,7 +713,7 @@
   return false;
   }
   MyAntTypeDefinition otherDef = (MyAntTypeDefinition) other;
  -return macroDef.equals(otherDef.macroDef);
  +return macroDef.similar(otherDef.macroDef);
   }
   }
   
  
  
  

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

DO NOT REPLY [Bug 28996] - [PATCH] Permit building under JDK 1.5 beta 2

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28996

[PATCH] Permit building under JDK 1.5 beta 2

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 13:24 ---
Commited, Thanks

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

cvs commit: ant build.xml

[peterreilly]

peterreilly2004/05/17 06:22:53

  Modified:.Tag: ANT_16_BRANCH build.xml
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.392.2.26 +5 -2  ant/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/ant/build.xml,v
  retrieving revision 1.392.2.25
  retrieving revision 1.392.2.26
  diff -u -r1.392.2.25 -r1.392.2.26
  --- build.xml 27 Apr 2004 07:45:47 -  1.392.2.25
  +++ build.xml 17 May 2004 13:22:52 -  1.392.2.26
  @@ -48,7 +48,8 @@
 
 
 
  -  
  +  
  +  
 
 
 
  @@ -603,6 +604,7 @@
  debug="${debug}"
  deprecation="${deprecation}"
  target="${javac.target}"
  +   source="${javac.source}"
  optimize="${optimize}" >
 
   
  @@ -1353,6 +1355,7 @@
  destdir="${build.tests}"
  debug="${debug}"
  target="${javac.target}"
  +   source="${javac.source}"
  deprecation="${deprecation}" >
 
   
  @@ -1607,4 +1610,4 @@
 description="--> creates a minimum distribution in ./dist"
 depends="dist-lite"/>
   
  -
  \ No newline at end of file
  +
  
  
  

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

cvs commit: ant build.xml

[peterreilly]

peterreilly2004/05/17 06:22:12

  Modified:.build.xml
  Log:
  Permit building under JDK 1.5
  PR: 28996
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.419 +5 -2  ant/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/ant/build.xml,v
  retrieving revision 1.418
  retrieving revision 1.419
  diff -u -r1.418 -r1.419
  --- build.xml 27 Apr 2004 07:44:46 -  1.418
  +++ build.xml 17 May 2004 13:22:11 -  1.419
  @@ -48,7 +48,8 @@
 
 
 
  -  
  +  
  +  
 
 
 
  @@ -604,6 +605,7 @@
  debug="${debug}"
  deprecation="${deprecation}"
  target="${javac.target}"
  +   source="${javac.source}"
  optimize="${optimize}" >
 
   
  @@ -1354,6 +1356,7 @@
  destdir="${build.tests}"
  debug="${debug}"
  target="${javac.target}"
  +   source="${javac.source}"
  deprecation="${deprecation}" >
 
   
  @@ -1610,4 +1613,4 @@
 description="--> creates a minimum distribution in ./dist"
 depends="dist-lite"/>
   
  -
  \ No newline at end of file
  +
  
  
  

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

Re: antlibs and classloaders #2

[Peter Reilly]

Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED] 

I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml

 
   
 

This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up 
two antlib.xml resources, the one in  
"${user.home}/apps/x/x.jar" and the one in x_call.jar 
(itself). This will should cause no-ending recursion.

The bug means that this does no happen - the resources in the 
parent classloader are currently not visible to the child 
classloaders.

If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already 
been executed.  This can be done by using "user" properties - 
but this will pollute the property names, or by exending 
(again) Project to have a map of objects that gets copied to 
its child projects. Using non-user properties or references 
will not work as <*ant*> tasks can stop the non-user 
properties and references being copied to the child 
processes. Using a static map in typedef will not work as 
sibling projects will incorrectly interact.

   

This things sound like we are using the wrong abstraction here.
 inside an  should use the antlib classloader
as the parent for any subsequent classloader.
 

In this case the parent is the antlib classloader (it is the default 
classloader).

I do not see why that should cause an infinite recursion.
 

The problem is that the 
  in
the antlib will pick up the antlib.xml resoure that contains 
task which will pick up .,

This does not happen with the current ant code, as the 
 
task will not see the antlib.xml resource in the parent classloader.

Another way to work-around this is for the typedef to use a thread 
specific stack to check
for recursive loading of xml resources.
This probally should be done in any case:

recursive.xml

  

build.xml:

 

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

DO NOT REPLY [Bug 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 12:58 ---
Thank you, I also saw the -tag in ant-contrib, but of course I dislike
the idea of having to install custom enhancements for such a fundamental 
feature.

Nevertheless, I already said it posed no problem for me - in fact, it only came
into my mind while "antin'" ;).

I'm sure this has been discussed already while developing Ant, but i'm pointing
out an alternative way of thinking with the keyword: "consistency,
functionality, simplicity". As this could be quite useful for the Ant team at
some points... ;)

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

DO NOT REPLY [Bug 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 12:52 ---
I had written a template for my own:










Just  it and use it nearly as your example:


  

  
  

  


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

DO NOT REPLY [Bug 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 12:51 ---
As a work-around, you could try  from ant-contrib:

  
 

 
 

   
 
 
   


or using a cvs head version of 

  
 
 

   
 
 
   


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

Re: antlibs and classloaders #2

[Peter Reilly]

I would agree with you on all points (I think).
Mariano Benitez wrote:

This things sound like we are using the wrong abstraction here.
 inside an  should use the antlib classloader
as the parent for any subsequent classloader.
I do not see why that should cause an infinite recursion.
I feel like we have a conceptual mismatch between antlib "the jar"
with the code, and antlib "the resource with the XML definitions".
We are not treating them in a symetric way or as a unit. And
hence we are get into all this conflicting behaviour.
 

I would like to pick from here and try to describe my understanding of 
the concepts.

Antlib: I see this as a a definition of tasks within a namespace that 
involves all the jars required to resolve the execution of the tasks. 
To put it plainly, I see it as the antlib.xml with a classpath.
This classpath could be defined by a  task.
   So for me that defines completely the antlib and the extra 
classpath should be added to the antlib classpath.

   Also, for me is accidental that the antlibs should be located in 
the $ANT_HOME/lib or in a -lib , actually the antlib definition 
should start from the antlib.xml, wherever it is, and then create a 
classloader based on the antlib definition.

   For the special case were the antlib jars are located in the base 
ant classpath ($ANT_HOME/lib or -lib ) I would not allow adding 
a classpath since the antlib should be completely contained within the 
base ant classpath, only when the antlib jars are outside I would 
allow defining an extra classpath.

   Also, defining antlibs in either way (being inside base ant 
classpath or outside) should behave the same way, they should be 
idempotent, meaning that once they are defined, they should not be 
overriden, I understand that it is not wise to use the same uri for 
different antlibs, the user should always try to pick unique names for 
the antlibs, otherwise we go back to a single namespace.
One antlib may "resolve" other antlibs if antlibresolve was an allowed 
task in an antlib.

Peter

This is my understanding of antlibs, it is probably out of synch with 
what you envision on this, but I wanted to let you know what I thought 
antlibs were about.

My 2 cents.
MAriano
-
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 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 12:44 ---
I could easily avoid the need, as I can write multiple copy statements.

What I would like to see:

  



  
  
 

 
  


The question is; why not?
Maybe not many people need it, but still it's handy and last but not least: it's
consistent. Why am I able to define a nested fileset for the source then? That's
also not really needed, I could also write multiple copy statements for that.

You don't see the need, *except* 
The latter is just the need. Practical example: you want to keep 2 or more build
output dirs, for some reason.

It just opens up possibilities which will greatly reduce the footprint of the
build.xml file in some cases.

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

Re: antlibs and classloaders #2

[Mariano Benitez]

This things sound like we are using the wrong abstraction here.
 inside an  should use the antlib classloader
as the parent for any subsequent classloader.
I do not see why that should cause an infinite recursion.
I feel like we have a conceptual mismatch between antlib "the jar"
with the code, and antlib "the resource with the XML definitions".
We are not treating them in a symetric way or as a unit. And
hence we are get into all this conflicting behaviour.
 

I would like to pick from here and try to describe my understanding of 
the concepts.

Antlib: I see this as a a definition of tasks within a namespace that 
involves all the jars required to resolve the execution of the tasks. To 
put it plainly, I see it as the antlib.xml with a classpath.
   So for me that defines completely the antlib and the extra classpath 
should be added to the antlib classpath.

   Also, for me is accidental that the antlibs should be located in the 
$ANT_HOME/lib or in a -lib , actually the antlib definition should 
start from the antlib.xml, wherever it is, and then create a classloader 
based on the antlib definition.

   For the special case were the antlib jars are located in the base 
ant classpath ($ANT_HOME/lib or -lib ) I would not allow adding a 
classpath since the antlib should be completely contained within the 
base ant classpath, only when the antlib jars are outside I would allow 
defining an extra classpath.

   Also, defining antlibs in either way (being inside base ant 
classpath or outside) should behave the same way, they should be 
idempotent, meaning that once they are defined, they should not be 
overriden, I understand that it is not wise to use the same uri for 
different antlibs, the user should always try to pick unique names for 
the antlibs, otherwise we go back to a single namespace.

This is my understanding of antlibs, it is probably out of synch with 
what you envision on this, but I wanted to let you know what I thought 
antlibs were about.

My 2 cents.
MAriano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: antlibs and classloaders #2

[Jose Alberto Fernandez]

> From: Peter Reilly [mailto:[EMAIL PROTECTED] 
> 
> 
> I meant to respond to this earlier, but did not get the chance.
> 
> 1) use of classpath in an antlib.
> I have tested using a classpath within an antlib:
> 
> ~/.ant/lib/x_call.jar containing:
> x/antlib.xml
> 
>   
> 
>   
> 
> 
> This works fine, but depends on a possible bug in ant
> see: bugzilla 28782
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
> 
> The problem is that the typedef in the antlib should pick up 
> two antlib.xml resources, the one in  
> "${user.home}/apps/x/x.jar" and the one in x_call.jar 
> (itself). This will should cause no-ending recursion.
> 
> The bug means that this does no happen - the resources in the 
> parent classloader are currently not visible to the child 
> classloaders.
> 
> If the bug is fixed, an infinite recursion will happen.
> This could be stopped by typedef checking if it has already 
> been executed.  This can be done by using "user" properties - 
> but this will pollute the property names, or by exending 
> (again) Project to have a map of objects that gets copied to 
> its child projects. Using non-user properties or references 
> will not work as <*ant*> tasks can stop the non-user 
> properties and references being copied to the child 
> processes. Using a static map in typedef will not work as 
> sibling projects will incorrectly interact.
> 

This things sound like we are using the wrong abstraction here.
 inside an  should use the antlib classloader
as the parent for any subsequent classloader.

I do not see why that should cause an infinite recursion.

I feel like we have a conceptual mismatch between antlib "the jar"
with the code, and antlib "the resource with the XML definitions".
We are not treating them in a symetric way or as a unit. And
hence we are get into all this conflicting behaviour.

> 2) antlibresolve
> I like the idea of antlibresolve:
> 
> 
> 
> 
> This would use ComponentHelper#checkedNamespaces to see
> if the antlib has been resolved or not, which means that
> it can be called many times without a problems.
> 
> 
> Using:
> 
>   .
>   .
>   
> 
>   
> 
> 
> May be considered as a short-hand (antlibresolve is now a 
> reserved name and may not be used as a task/type in an antlib).
> 

You are right, but I like it since it reduces the amount of retyping
of long URIs that we would have otherwise. As, how to treat such
"reserve word", is to be automatically added by  as a
predefined
task of all namespaces.

> 
> However:
>   
>   
> 
> is very problematic. - for example the antlibresolve may be in a
> macrodef:
>
>   ...
>  
>  
>   ...
>
> 
>
> 

I see the problems...

Jose Alberto

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

DO NOT REPLY [Bug 28995] - [PATCH] Ignore built distributions

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28995

[PATCH] Ignore built distributions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 10:42 ---
Committed Thanks.

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

cvs commit: ant .cvsignore

[peterreilly]

peterreilly2004/05/17 03:41:13

  Modified:.Tag: ANT_16_BRANCH .cvsignore
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.10.2.1  +3 -0  ant/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/ant/.cvsignore,v
  retrieving revision 1.10
  retrieving revision 1.10.2.1
  diff -u -r1.10 -r1.10.2.1
  --- .cvsignore2 Sep 2003 14:49:38 -   1.10
  +++ .cvsignore17 May 2004 10:41:12 -  1.10.2.1
  @@ -10,3 +10,6 @@
   velocity.log*
   patch.txt
   patch.tar.gz
  +.classpath
  +.project
  +apache-ant-1.*
  
  
  

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

cvs commit: ant .cvsignore

[peterreilly]

peterreilly2004/05/17 03:40:19

  Modified:..cvsignore
  Log:
  Ignore built distributions for cvs
  PR: 11557
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.12  +1 -0  ant/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/ant/.cvsignore,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- .cvsignore6 Apr 2004 13:18:47 -   1.11
  +++ .cvsignore17 May 2004 10:40:19 -  1.12
  @@ -12,3 +12,4 @@
   patch.tar.gz
   .classpath
   .project
  +apache-ant-1.*
  
  
  

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

DO NOT REPLY [Bug 28997] - [PATCH] Remove redundant from javah.html

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28997

[PATCH] Remove redundant  from javah.html

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 10:37 ---
Committed, thanks.

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

cvs commit: ant/docs/manual/OptionalTasks javah.html

[peterreilly]

peterreilly2004/05/17 03:35:41

  Modified:docs/manual/OptionalTasks Tag: ANT_16_BRANCH javah.html
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.6.2.3   +0 -3  ant/docs/manual/OptionalTasks/javah.html
  
  Index: javah.html
  ===
  RCS file: /home/cvs/ant/docs/manual/OptionalTasks/javah.html,v
  retrieving revision 1.6.2.2
  retrieving revision 1.6.2.3
  diff -u -r1.6.2.2 -r1.6.2.3
  --- javah.html9 Feb 2004 22:12:11 -   1.6.2.2
  +++ javah.html17 May 2004 10:35:41 -  1.6.2.3
  @@ -111,11 +111,8 @@
   describe its progress.
   
   
  -
  -
   Copyright © 2001-2002,2004 The Apache Software 
Foundation. All rights
   Reserved.
   
   
   
  -
  
  
  

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

cvs commit: ant/docs/manual/OptionalTasks javah.html

[peterreilly]

peterreilly2004/05/17 03:35:15

  Modified:docs/manual/OptionalTasks javah.html
  Log:
  Remove redundant  from javah.htm
  PR: 11559
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.8   +0 -3  ant/docs/manual/OptionalTasks/javah.html
  
  Index: javah.html
  ===
  RCS file: /home/cvs/ant/docs/manual/OptionalTasks/javah.html,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- javah.html9 Feb 2004 21:50:08 -   1.7
  +++ javah.html17 May 2004 10:35:15 -  1.8
  @@ -110,11 +110,8 @@
   describe its progress.
   
   
  -
  -
   Copyright © 2001-2002,2004 The Apache Software 
Foundation. All rights
   Reserved.
   
   
   
  -
  
  
  

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

DO NOT REPLY [Bug 29030] New: - Problem in compiling ejb's using ant 1.4.1 in WSAD 5.0

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29030

Problem in compiling ejb's using ant 1.4.1 in WSAD 5.0  

   Summary: Problem in compiling ejb's using ant 1.4.1 in WSAD 5.0
   Product: Ant
   Version: 1.4.1
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Build Process
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I deployed Ejb- a stateless session bean on the Server., when i executed Run 
Ant From my WSAD, in the ejb-compile task, 

It is throwing following Error : 

The import com.ibm.ejs.container.EJSHome cannot be resolved
The import com.ibm.ejs.EJSException is never used
EJSHome cannot be resolved or is not a valid superclass
BeanO cannot be resolved or is not a type
BeanId cannot be resolved or is not a type
EJSWrapper cannot be resolved or is not a valid superclass
EJSDeployedSupport cannot be resolved or is not a type


Please help me out.


Thanks a lot

Shravan

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

DO NOT REPLY [Bug 28999] - [PATCH] Misc. corrections in SignJar.java

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28999

[PATCH] Misc. corrections in SignJar.java

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 10:24 ---
Commits, thanks.

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

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

[peterreilly]

peterreilly2004/05/17 03:18:30

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
SignJar.java
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.31.2.5  +8 -5  ant/src/main/org/apache/tools/ant/taskdefs/SignJar.java
  
  Index: SignJar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/SignJar.java,v
  retrieving revision 1.31.2.4
  retrieving revision 1.31.2.5
  diff -u -r1.31.2.4 -r1.31.2.5
  --- SignJar.java  9 Mar 2004 17:01:34 -   1.31.2.4
  +++ SignJar.java  17 May 2004 10:18:30 -  1.31.2.5
  @@ -30,14 +30,11 @@
   import org.apache.tools.ant.util.JavaEnvUtils;
   
   /**
  - * Signs jar or zip files with the javasign command line tool. The
  + * Signs JAR or ZIP files with the javasign command line tool. The
* tool detailed dependency checking: files are only signed if they
* are not signed. The signjar attribute can point to the file to
* generate; if this file exists then
* its modification date is used as a cue as to whether to resign any JAR 
file.
  - * 
  - * Note: Requires Java 1.2 or later. 
  -
*
* @since Ant 1.1
* @ant.task category="java"
  @@ -299,7 +296,7 @@
   
   cmd.createArg().setValue(alias);
   
  -log("Signing Jar : " + jarSource.getAbsolutePath());
  +log("Signing JAR: " + jarSource.getAbsolutePath());
   cmd.setFailonerror(true);
   cmd.setTaskName(getTaskName());
   cmd.execute();
  @@ -333,6 +330,12 @@
   return false;
   }
   
  +/**
  + * test for a file being signed, by looking for a signature in the 
META-INF
  + * directory
  + * @param file
  + * @return true if the file is signed
  + */
   protected boolean isSigned(File file) {
   final String SIG_START = "META-INF/";
   final String SIG_END = ".SF";
  
  
  

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

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

[peterreilly]

peterreilly2004/05/17 03:12:30

  Modified:src/main/org/apache/tools/ant/taskdefs SignJar.java
  Log:
  Misc. corrections in SignJar.java
  PR: 28999
  Obtained from: Jesse Glick
  
  Revision  ChangesPath
  1.37  +3 -6  ant/src/main/org/apache/tools/ant/taskdefs/SignJar.java
  
  Index: SignJar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/SignJar.java,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- SignJar.java  22 Apr 2004 14:03:47 -  1.36
  +++ SignJar.java  17 May 2004 10:12:29 -  1.37
  @@ -31,14 +31,11 @@
   import org.apache.tools.ant.util.FileUtils;
   
   /**
  - * Signs jar or zip files with the javasign command line tool. The
  + * Signs JAR or ZIP files with the javasign command line tool. The
* tool detailed dependency checking: files are only signed if they
* are not signed. The signjar attribute can point to the file to
* generate; if this file exists then
* its modification date is used as a cue as to whether to resign any JAR 
file.
  - * 
  - * Note: Requires Java 1.2 or later. 
  -
*
* @since Ant 1.1
* @ant.task category="java"
  @@ -300,7 +297,7 @@
   
   cmd.createArg().setValue(alias);
   
  -log("Signing Jar : " + jarSource.getAbsolutePath());
  +log("Signing JAR: " + jarSource.getAbsolutePath());
   cmd.setFailonerror(true);
   cmd.setTaskName(getTaskName());
   cmd.execute();
  @@ -338,7 +335,7 @@
* test for a file being signed, by looking for a signature in the 
META-INF
* directory
* @param file
  - * @return
  + * @return true if the file is signed
*/
   protected boolean isSigned(File file) {
   final String SIG_START = "META-INF/";
  
  
  

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

Re: antlibs and classloaders #2

[Peter Reilly]

I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml

 
   
 

This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in  "${user.home}/apps/x/x.jar"
and the one in x_call.jar (itself). This will should
cause no-ending recursion.
The bug means that this does no happen - the resources in the parent
classloader are currently not visible to the child classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already been
executed.  This can be done by using "user" properties - but this
will pollute the property names, or by exending (again) Project to
have a map of objects that gets copied to its child projects. Using
non-user properties or references will not work as <*ant*> tasks can
stop the non-user properties and references being copied to the
child processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
2) antlibresolve
I like the idea of antlibresolve:

  

This would use ComponentHelper#checkedNamespaces to see
if the antlib has been resolved or not, which means that
it can be called many times without a problems.
Using:

 .
 .
 
   
 

May be considered as a short-hand (antlibresolve is now a reserved
name and may not be used as a task/type in an antlib).
However:
 
 
is very problematic. - for example the antlibresolve may be in a
macrodef:
  
 ...


 ...
  
  
Peter
 

Jose Alberto Fernandez wrote:
From: Mariano Benitez [mailto:[EMAIL PROTECTED] 

Let me get this right.. this task would define the antlib classes the 
moment it is invoked, and it should be used on the top level 
buildfile, 
this way the subbuilds/subants/ant/antcall targets have the antlib 
already loaded, right?

I explain a bit my build files structure for testing:
   

[snip...]
 

Up to this moment I need to define the tasks in boths includes using 
 because I 
cannot pass classpath to antlibs. I also added in both includes an 
...the typedef 
stuff.  to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult 
to control 
in all the builds that the do use inheritall="true", since 
otherwise the 
 would not find the property and redefine the tasks.

   

 


Here I would advocate to have the new condition 
that I mentioned before. Which will not rely on inheritAll
but will look at the definintion dictionalries directly.
 

Could you put this structure as it would be in 1.6.2 with the 
antlibresolve and antlib classpath, at least what you imagine 
it might be?

I like the  solution, as long as it does not 
redefine the 
tasks, or at least there is an option not to do so. Would it 
be possible 
to add to typedef that possibility?

   

 the only thing it does is make sure the antlib URI
gets processed. As if you were calling task in the space of the antlib.
Actually on the incarnation as 
it would have been a noop task whose only side-effect is causing the
loading of the antlib. If you call it 20 times it would only load
the antlib the first time, like any other task would.
(humm this may be still the best solution, just make every antlib define
this task).
How to deal with your classloaders, that is a different thing
completely. 
- Is it possible to define them inside the antlib (or are they buildfile
dependent)?
- I had proposed in the past a naming convention to associate a
classpath/loader
with a particular URI. But all this is just open talk at the moment.
- Maybe  can do some of this, but then its definition is
not as clean
as one would want.

Jose Alberto
 

Thanks for the help on this matter.
MAriano
Jose Alberto Fernandez wrote:
   

From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
  

   

Would the following solve this problem generically?




 

looks like a reasonable compromise.
The alternative would be a built-in task that takes the
antlib URI, this wouldn't even require any magic taskname.
 or even .
  

   

I have no problem, one way or another, as long as I do not 
 

have to type 
   

the whole URI again ;-) This is why I want to use the NS prefix 
instead. Is there an way for the task to get the information needed 
(the URI)?

Since a lot of this is resolved by the parser (prefix-->uri) 
 

mapping, I 
   

was trying to make sure we do not get bog by the design. So 
 

as long as 
   

we can get the info necessary by just saying:
 
or
 
In this second, we get the URI from "ns" attribute which is in that 
space. the implementation could use the new NS aware 
 

features that were 
   

added recently.
Jose Alberto

DO NOT REPLY [Bug 29011] - Enhance the -tag to support filesets for both source *and* destination

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29011

Enhance the -tag to support filesets for both source *and* destination





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 07:03 ---
I don´t see the need of specifying multiple dest-dirs, except you only want 
multiple copies.

Can you provide an example what you want to have?

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

DO NOT REPLY [Bug 28984] - Optional ccm tasks only run on windows, patch for linux compatibility

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28984

Optional ccm tasks only run on windows, patch for linux compatibility

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 06:57 ---
I am on a rewrite on that section. Mostly I´m adding some more tasks 
(create/delete project, get session information, ...). On Windows you can also 
use "-", so I can change that globally. But I would be happy if you can test 
the new tasks on Unix :-)

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