DO NOT REPLY [Bug 40291] - classpath uses colon, ":", as path separator under windows

[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=40291





--- Additional Comments From [EMAIL PROTECTED]  2006-08-24 05:15 ---
Using  does not help.

Also, the comment about being platform independent doesn't make sense to me.
Something, and it appears to be ant since it happens when I run from the command
line, is concatenating the path on the fly. Why shouldn't it just use
${path.separator} when it creates the path instead of doing a string.replace()
later on, especially since msdos uses ":" for a second purpose. As for a
programmer using a literal instead of the symbolic parameter, they should be
shot (nb, I had to convert a large Java app that used "\" in file names to run
on linux -- it ain't fun when it could have been done right to begin with).

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

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

Re: classloader for 1.7

[Kev Jackson]

On Wed, 2006-08-23 at 10:33 +0100, Steve Loughran wrote:
> Peter Reilly wrote:
> > If it is not a little too late, I would like to get a vote
> > on including classloader into ant 1.7.
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=28228)
> > I have been playing with it the last week or so. It really makes
> > working with antlibs, and scripting different languages very
> > nice. For example: Rather that having a lot of jar files in ~/.ant/lib, I
> > can
> > have a number of directories that contain all that is needed
> > for a particular language and load that into the build file. using a macro
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 
> > This is especially true for working with JDK 1.6 scripting - one needs
> > an extra jar file for each language.
> > 
> > I have been using classloader with netbeans, and my worry before about
> > it messing up the classloader does not seem to be true. In fact, for groovy
> > and ruby the start up cost of the language is done once, and after that
> > scripts run very fast.
> 

Ok, as you guys know, I'm interested in anything that will help
scripting in Java/Ant, so this does interest me *a lot*. My only worry
is how the classloader task is that I have very little knowledge about
all the possible effects changing classloaders can have on
builds/projects.  I know for example that the delegating classloader we
currently have causes strangeness with JUnit (hence the FAQ entry), and
I'd hate to introduce another issue with classloaders that will cause
people to think that Ant simply has classloading problems full stop.

With all my worries aside, from a user perspective, the 
example above is about as cool as it gets w.r.t loading a bsf language -
it's exactly what the bsf guys want to be able to do - make java apps
scriptable with minimum fuss.

In netbeans, what is the startup cost?  Does it have a considerable
impact on the startup of the application to include scripting support?

For now I'm +0 - go for it as long as Antoine is happy.  We can try it
in the beta and then if people have issues we pull it from the main
release - I'm certainly not going to veto without having evidence of
widespread discontent from the users.  This will mean however that a
longer beta period would be required so that we can gather sufficient
feedback to evaluate if everything is ok or not.

Personally I want to see this in the release so that we can easily ship
scriptdef based antlibs (with dynamic language of choice :)

Kev


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

Re: Use of reflection in DirectoryScanner to remove duplicated code

[Kev Jackson]

> > 
> > For additional testing I've created a directory/file structure like
> > 
> > 1/
> >1 2/
> > 2 3/
> >  3 4/
> 
> so much effort ...
> 

nah, 5 lines of script - I wasn't going to do it manually :)

> I assume you tried some combinations of include/excludes.  Dominique
> used to have a big tree where any change to DirectoryScanner affected
> the runtime of the  task considerably ( needs to scan both
> the source and the dest tree), but that probably was part of another
> live of his.
> 

I wonder if Dominique still has access to that tree, as a real world
tree would be a better test of changes than an artificial construct.
Antoine has mentioned that he would prefer not to use reflection for the
simple reason that some tools cannot show the method graph - in this
particular case I can't see that being a problem as no methods are
called using reflection, I'm only using it to gain access to fields.  I
think in general a change to such a core part of the code *must* be
thoroughly checked/tested for performance issues, so to facilitate this
I've attached the change as a patch (svn diff).  If someone has a
real-world pathological case to try this against I'd love to see the
results of a before-patch/after-patch run.  I'm not considering this
change as possible to go into the trunk until after the release of the
Beta (and probably will be held back for the next release ~1.8)

Thanks for comments so far - here's the patch (it may have tabs in it,
Eclipse on Ubuntu defaults to tabs for some reason, I stripped out the
ones I could find and changed to 4 spaces, but may have missed some)

Kev
Index: .
===
--- .	(revision 434293)
+++ .	(working copy)
@@ -1115,21 +1115,22 @@
  * @param file  included File.
  */
 private void accountForIncludedFile(String name, File file) {
-if (filesIncluded.contains(name)
-|| filesExcluded.contains(name)
-|| filesDeselected.contains(name)) {
-return;
-}
-boolean included = false;
-if (isExcluded(name)) {
-filesExcluded.addElement(name);
-} else if (isSelected(name, file)) {
-included = true;
-filesIncluded.addElement(name);
-} else {
-filesDeselected.addElement(name);
-}
-everythingIncluded &= included;
+//if (filesIncluded.contains(name)
+//|| filesExcluded.contains(name)
+//|| filesDeselected.contains(name)) {
+//return;
+//}
+//boolean included = false;
+//if (isExcluded(name)) {
+//filesExcluded.addElement(name);
+//} else if (isSelected(name, file)) {
+//included = true;
+//filesIncluded.addElement(name);
+//} else {
+//filesDeselected.addElement(name);
+//}
+//everythingIncluded &= included;
+	processIncluded(name, file, "files");
 }
 
 /**
@@ -1140,21 +1141,22 @@
  * @param fast whether to perform fast scans.
  */
 private void accountForIncludedDir(String name, File file, boolean fast) {
-if (dirsIncluded.contains(name)
-|| dirsExcluded.contains(name)
-|| dirsDeselected.contains(name)) {
-return;
-}
-boolean included = false;
-if (isExcluded(name)) {
-dirsExcluded.addElement(name);
-} else if (isSelected(name, file)) {
-included = true;
-dirsIncluded.addElement(name);
-} else {
-dirsDeselected.addElement(name);
-}
-everythingIncluded &= included;
+//if (dirsIncluded.contains(name)
+//|| dirsExcluded.contains(name)
+//|| dirsDeselected.contains(name)) {
+//return;
+//}
+//boolean included = false;
+//if (isExcluded(name)) {
+//dirsExcluded.addElement(name);
+//} else if (isSelected(name, file)) {
+//included = true;
+//dirsIncluded.addElement(name);
+//} else {
+//dirsDeselected.addElement(name);
+//}
+//everythingIncluded &= included;
+	processIncluded(name, file, "dirs");
 if (fast && couldHoldIncluded(name) && !contentsExcluded(name)) {
 scandir(file, name + File.separator, fast);
 }
@@ -1159,6 +1161,33 @@
 scandir(file, name + File.separator, fast);
 }
 }
+
+private void processIncluded(String name, File file, String dirOrFile) {
+	try {
+		Vector inc = (Vector)this.getClass().getDeclaredField(dirOrFile+"Included").get(this);
+		Vector exc = (Vector)this.getClass().getDeclaredField(dirOrFile+"Excluded").get(this);
+		Vector des = (Vector)this.getClass().getDeclaredField(dirOrFile+"Deselected").get(this);
+		
+		if (inc.contains(name) || exc.contains(name) || des.contains(name)) { return; }

Re: svn commit: r433519 - /ant/antlibs/antunit/trunk/src/main/org/apache/ant/antunit/listener/XMLAntUnitListener.java

[Stefan Bodewig]

On Wed, 23 Aug 2006, Steve Loughran <[EMAIL PROTECTED]> wrote:

>> make XML report a bit prettier
> 
> For the smartfrog xml junit reporting, I can stick out XHTML content
> instead of dumb XML. That means that the results are ready-to-read,
> without any XSL operation.

I intend to add new stylesheets so that you can run  on
it.  Because of this I try to remain as close to the JUnit test report
format as possible ( performs some internal magic while
merging the reports) while making it possible to stream the report at
the same time.

We can always add an XHTML listener as well.

Stefan

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

Re: Use of reflection in DirectoryScanner to remove duplicated code

[Stefan Bodewig]

On Wed, 23 Aug 2006, Kev Jackson <[EMAIL PROTECTED]> wrote:
> Hi Stefan, (and other interested devs)
> 
> For additional testing I've created a directory/file structure like
> 
> 1/
>1 2/
> 2 3/
>  3 4/

so much effort ...

> ie a single file under a directory, the tree is 1038+ layers deep
> and there is no difference between the original time taken by the
> DirectoryScanner code and the modified code

I assume you tried some combinations of include/excludes.  Dominique
used to have a big tree where any change to DirectoryScanner affected
the runtime of the  task considerably ( needs to scan both
the source and the dest tree), but that probably was part of another
live of his.

Stefan

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

Re: classloader for 1.7

[Stefan Bodewig]

On Wed, 23 Aug 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:

> The one in 1.6 does not work.

Didn't know that.

> The proposed one is totally different.

But its intention is the same and so my opinion is the same, add a
warning to the docs and it's OK.

The only thing I'd be concerned about is timing.  You'd need to have
it inside of Ant before Antoine put together the beta release.  I
probably won't find the time to help, so not a +1 but certainly not a
-1 either.

Stefan

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

Re: [PROPOSAL] Release Plan .NET Antlib

[Steve Loughran]

Stefan Bodewig wrote:

Hi all,

I propose the following plan, please comment.

* copy all classes from Ant core's /taskdefs/optional/dotnet to
  the .NET Antlib, in particular put into .../ant/dotnet/compile



+1


  I'm not 100% sure that "compile" is the right place for  and
  .


yeah, stick them in misc


* Add deprecation warnings to the .NET tasks in Ant core.


+1. Include a URL


* move the  task into a new subdirectory WiX - I'm working on
  additional WiX support but it isn't finished and won't be until we
  make a release.


+1


* move the  and  tasks to a new subdirectory build.


+1


* find anybody who'd beautify the docs - not strictly necessary for a
  beta release.


I want more automated doc generation.


* release a first beta by the end of August (can't plan my next week
  in detail right now, sorry).


+0. Your choice.


Stefan

-
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: classloader for 1.7

[Steve Loughran]

Peter Reilly wrote:

If it is not a little too late, I would like to get a vote
on including classloader into ant 1.7.
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28228)
I have been playing with it the last week or so. It really makes
working with antlibs, and scripting different languages very
nice. For example: Rather that having a lot of jar files in ~/.ant/lib, I
can
have a number of directories that contain all that is needed
for a particular language and load that into the build file. using a macro

   
   
   
   
   
   
   
   
   
   

This is especially true for working with JDK 1.6 scripting - one needs
an extra jar file for each language.

I have been using classloader with netbeans, and my worry before about
it messing up the classloader does not seem to be true. In fact, for groovy
and ruby the start up cost of the language is done once, and after that
scripts run very fast.


+1, with the caveat that we will pull it if it causes too many 
complaints. But I also give Kevin veto rights, he being release manager 
and all.



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

Re: svn commit: r433519 - /ant/antlibs/antunit/trunk/src/main/org/apache/ant/antunit/listener/XMLAntUnitListener.java

[Steve Loughran]

[EMAIL PROTECTED] wrote:

Author: bodewig
Date: Mon Aug 21 22:00:55 2006
New Revision: 433519

URL: http://svn.apache.org/viewvc?rev=433519&view=rev
Log:
make XML report a bit prettier



For the smartfrog xml junit reporting, I can stick out XHTML content 
instead of dumb XML. That means that the results are ready-to-read, 
without any XSL operation.


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

Re: Can DefaultLogger record the time on each target transition?

[Steve Loughran]

Jeffrey E Care wrote:


In addition to backwards compatibility, there are other issues to consider:

1) Granularity: why limit timing data to targets? why not extend it to 
tasks as well?

2) Filtering: do you want timing data for every target? every task?

and the big one

3) Multithreading: as the committers on this list will tell you, I'm 
always thinking about this one. At IBM, we use Ant + in-house antlibs to 
build the WebSphere family of products. We're fortunate to have very 
good hardware in our build lab, and with products as large as WebSphere 
we're keen on making the most efficient use of it; one of the ways we do 
that is to multithread our builds. In our initial experiments we wanted 
to get timing data to compare against our single-threaded builds, so we 
wrote our own custom logger (just slight changes to the default logger) 
to print the timings. When we ran the builds, everything went haywire.


The upshot is that we had to write our own logger from scratch to meet 
our needs for running in a multithreaded environment. I know that most 
people don't do this, but I don't think we should be introducing code 
into Ant that we KNOW doesn't work in certain cases.




+1

I'm all for logging time data, and I have switched to using the logger 
of ant1.7 that prints out when a build finished. But any change to the 
log can break things. Even adding the time of build success/failure was 
enough to break luntbuild, that was looking for a string as well as an 
exit code.


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

Re: FileSet inside MacroDef causing ClassCastException

[Hari Krishna Dara]

-- Forwarded message --
From: "Peter Reilly" <[EMAIL PROTECTED]>
To: "Ant Developers List" 
Date: Wed, 23 Aug 2006 23:26:09 +0100
Subject: Re: FileSet inside MacroDef causing ClassCastException
This is a different problem to MATs.
This problem is due to the resolution of references.
The build script can be reduced to:


  

  

  







When the script task is executed, it converts all
ant references to script variables (yuck). Ant references
are set at parse time (double yuck) and so the "fs"
reference will be resolved, this resolution converts the UnknownElement
to a "real" object (triple yuck) which causes the bug.
The last behaviour could be modified - but it is tricky
code and it is difficult to modify without causing more bugs
and backward compatibly problems.

Peter



Thanks Peter. Your simpler test case is more reliable than mine for
reproducing the problem. As a workaround, I have put a condition
around addBean() method to ignore anything except "project"
(conditional to a System property), which is the only thing I am using
from the scripts. I will internally document to have the system
property set before running this build script, and I hope that this
bug will some day be fixed. I appreciate your help in location the
problem area.

PS: I can report this as a bug on the bugzilla with your testcase if
you haven't already done so.



On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
>
> Here is a simpler test case, that removes some ambiguities. As you can
> see the content of the script task doesn't matter.
>
> 
>  default="test">
>
> 
> 
> 
>  ]]>
> 
> 
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
>
> 
> 
> Test !!
> 
> 
> 
> 
> 
> 
>
> 
>
>
>
> On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > > From: Mathieu Champlon <[EMAIL PROTECTED]>
> > > To: Ant Developers List 
> > > Date: Wed, 23 Aug 2006 14:50:20 +0900
> > > Subject: Re: FileSet inside MacroDef causing ClassCastException
> > > Hello !
> > >
> > > Hari Krishna Dara a écrit :
> > > > Can anyone provide any help in working around or fixing this
> problem?
> > >
> > > It looks like the same bug as
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?
> > >
> > > > Here is the macro that causes trouble (I stripped the sequence to
> the
> > > > least that causes theis problem, but as I said before, I couldn't
> copy
> > > > this into a standalone build file and reproduce the exception):
> > > >
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >
> > > > Here is the macro that is part of the same build file and works
> fine:
> > > >
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >   
> > > >> > > property="@{componentName}NeedsPatchTmp"
> > > >   refid="patchfileset"/>
> > > >   
> > > >   
> > > >> > > arg2=""/>
> > > >   
> > > >   
> > > >   
> > > >   
> > > How are your macro called ? With what 'selection' ?
> > > How many times each ? In which order ?
> > > What happens when you remove the call to the 'working' one ? (I
> suspect
> > > it 'fixes' the other :p)
> > >
> > > I'm not really surprised by the fact that it works fine when you copy
> > > your macros to a new build file, I had quite a lot of fun trying to
> > > reproduce the bug for the issue :)
> > > Actually what happens is that the same element is used either in
> several
> > > macros or several times in the same macro. Then as it gets resolved
> (and
> > > so is not an unknown element anymore) upon first use, it is no longer
> an
> > > UnknownElement for the remaining calls...
> > > I don't know if this makes sense, but anyway try and apply the patch
> and
> > > see if it fixes this issue for you ?
> > >
> > > MAT.
> >
> > I tried the patch suggested in the bug report on 1.6.2, but that
> > didn't solve the problem. So I applied the patch to 1.6.5 version, but
> > still I got the same exception. However, I was able to verify that the
> > patch fixes the testcase that you attached (by running before and
> > after applying the patch).
> >
> > Just like you guessed, if I comment the lines that are working, the
> > next two calls to this macro including the one that was failing
> > before, go through fine. This probably indicates that the problem you
> > reported and this are related, but there is still another case that is
> > not taken care of?
> >
> > Based upon your test cas

DO NOT REPLY [Bug 40238] - Nested generate class cast exception

[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=40238





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 22:31 ---
Yep, It looks like this is needed. I have
applied the patch. Thanks for the simple test case.
Peter

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

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

svn commit: r434226 - in /ant/core/trunk: CONTRIBUTORS WHATSNEW src/main/org/apache/tools/ant/taskdefs/MacroInstance.java

[peterreilly]

Author: peterreilly
Date: Wed Aug 23 15:32:36 2006
New Revision: 434226

URL: http://svn.apache.org/viewvc?rev=434226&view=rev
Log:
[PATCH] bugzilla  40238 - nested macrodef

Modified:
ant/core/trunk/CONTRIBUTORS
ant/core/trunk/WHATSNEW
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java

Modified: ant/core/trunk/CONTRIBUTORS
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/CONTRIBUTORS?rev=434226&r1=434225&r2=434226&view=diff
==
Binary files - no diff available.

Modified: ant/core/trunk/WHATSNEW
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=434226&r1=434225&r2=434226&view=diff
==
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Wed Aug 23 15:32:36 2006
@@ -270,6 +270,9 @@
 *  has a new adapter, xnew, to use the -XNew back end on java1.5+.
   By forking rmic, this works on java1.6+. Bugzilla report 38732.
 
+* Copy of UnknownElement in macroinstance was not recursive.
+  Bugzilla report 40238.
+
 Other changes:
 --
 

Modified: 
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java?rev=434226&r1=434225&r2=434226&view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java 
(original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java 
Wed Aug 23 15:32:36 2006
@@ -291,7 +291,7 @@
 }
 for (Iterator i = unknownElements.iterator();
  i.hasNext();) {
-UnknownElement child = (UnknownElement) i.next();
+UnknownElement child = copy((UnknownElement) i.next());
 rc.addChild(child.getWrapper());
 ret.addChild(child);
 }
@@ -307,7 +307,7 @@
 }
 for (Iterator i = list.iterator();
  i.hasNext();) {
-UnknownElement child = (UnknownElement) i.next();
+UnknownElement child = copy((UnknownElement) i.next());
 rc.addChild(child.getWrapper());
 ret.addChild(child);
 }



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

Re: FileSet inside MacroDef causing ClassCastException

[Peter Reilly]

This is a different problem to MATs.
This problem is due to the resolution of references.
The build script can be reduced to:


 
   
 
   
 

   

   



When the script task is executed, it converts all
ant references to script variables (yuck). Ant references
are set at parse time (double yuck) and so the "fs"
reference will be resolved, this resolution converts the UnknownElement
to a "real" object (triple yuck) which causes the bug.
The last behaviour could be modified - but it is tricky
code and it is difficult to modify without causing more bugs
and backward compatibly problems.

Peter


On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:


Here is a simpler test case, that removes some ambiguities. As you can
see the content of the script task doesn't matter.



























Test !!











On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > From: Mathieu Champlon <[EMAIL PROTECTED]>
> > To: Ant Developers List 
> > Date: Wed, 23 Aug 2006 14:50:20 +0900
> > Subject: Re: FileSet inside MacroDef causing ClassCastException
> > Hello !
> >
> > Hari Krishna Dara a écrit :
> > > Can anyone provide any help in working around or fixing this
problem?
> >
> > It looks like the same bug as
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?
> >
> > > Here is the macro that causes trouble (I stripped the sequence to
the
> > > least that causes theis problem, but as I said before, I couldn't
copy
> > > this into a standalone build file and reproduce the exception):
> > >
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >
> > > Here is the macro that is part of the same build file and works
fine:
> > >
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >   
> > >> > property="@{componentName}NeedsPatchTmp"
> > >   refid="patchfileset"/>
> > >   
> > >   
> > >> > arg2=""/>
> > >   
> > >   
> > >   
> > >   
> > How are your macro called ? With what 'selection' ?
> > How many times each ? In which order ?
> > What happens when you remove the call to the 'working' one ? (I
suspect
> > it 'fixes' the other :p)
> >
> > I'm not really surprised by the fact that it works fine when you copy
> > your macros to a new build file, I had quite a lot of fun trying to
> > reproduce the bug for the issue :)
> > Actually what happens is that the same element is used either in
several
> > macros or several times in the same macro. Then as it gets resolved
(and
> > so is not an unknown element anymore) upon first use, it is no longer
an
> > UnknownElement for the remaining calls...
> > I don't know if this makes sense, but anyway try and apply the patch
and
> > see if it fixes this issue for you ?
> >
> > MAT.
>
> I tried the patch suggested in the bug report on 1.6.2, but that
> didn't solve the problem. So I applied the patch to 1.6.5 version, but
> still I got the same exception. However, I was able to verify that the
> patch fixes the testcase that you attached (by running before and
> after applying the patch).
>
> Just like you guessed, if I comment the lines that are working, the
> next two calls to this macro including the one that was failing
> before, go through fine. This probably indicates that the problem you
> reported and this are related, but there is still another case that is
> not taken care of?
>
> Based upon your test case, and more trial and error of carefully
> commenting parts of the code, I narrowed down the macrodef's that are
> causing this problem. I am pasting a reproducible test case below, but
> it requires BeanShell/BSF jar files to be present in the classpath/ant
> lib directory (bsf.jar, bsh-2.0b4.jar and bsh-bsf-2.0b4.jar). Can
> anyone please take a look at this test case and give any guidance on
> how to find and fix the problem?
>
> PS: If anyone wants, I can send the above 3 jar files by email to make
> it easier for you to run the below testcase.
>
> Thank you,
> Hari
>

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

Re: FileSet inside MacroDef causing ClassCastException

[Hari Krishna Dara]

Here is a simpler test case, that removes some ambiguities. As you can
see the content of the script task doesn't matter.




   
   
   
   
   
   

   
   
   
   
   
   
   
   
   
   

   
   

   
   
   Test !!
   
   
   
   
   
   





On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:

> From: Mathieu Champlon <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Date: Wed, 23 Aug 2006 14:50:20 +0900
> Subject: Re: FileSet inside MacroDef causing ClassCastException
> Hello !
>
> Hari Krishna Dara a écrit :
> > Can anyone provide any help in working around or fixing this problem?
>
> It looks like the same bug as
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?
>
> > Here is the macro that causes trouble (I stripped the sequence to the
> > least that causes theis problem, but as I said before, I couldn't copy
> > this into a standalone build file and reproduce the exception):
> >
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >
> > Here is the macro that is part of the same build file and works fine:
> >
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >> property="@{componentName}NeedsPatchTmp"
> >   refid="patchfileset"/>
> >   
> >   
> >> arg2=""/>
> >   
> >   
> >   
> >   
> How are your macro called ? With what 'selection' ?
> How many times each ? In which order ?
> What happens when you remove the call to the 'working' one ? (I suspect
> it 'fixes' the other :p)
>
> I'm not really surprised by the fact that it works fine when you copy
> your macros to a new build file, I had quite a lot of fun trying to
> reproduce the bug for the issue :)
> Actually what happens is that the same element is used either in several
> macros or several times in the same macro. Then as it gets resolved (and
> so is not an unknown element anymore) upon first use, it is no longer an
> UnknownElement for the remaining calls...
> I don't know if this makes sense, but anyway try and apply the patch and
> see if it fixes this issue for you ?
>
> MAT.

I tried the patch suggested in the bug report on 1.6.2, but that
didn't solve the problem. So I applied the patch to 1.6.5 version, but
still I got the same exception. However, I was able to verify that the
patch fixes the testcase that you attached (by running before and
after applying the patch).

Just like you guessed, if I comment the lines that are working, the
next two calls to this macro including the one that was failing
before, go through fine. This probably indicates that the problem you
reported and this are related, but there is still another case that is
not taken care of?

Based upon your test case, and more trial and error of carefully
commenting parts of the code, I narrowed down the macrodef's that are
causing this problem. I am pasting a reproducible test case below, but
it requires BeanShell/BSF jar files to be present in the classpath/ant
lib directory (bsf.jar, bsh-2.0b4.jar and bsh-bsf-2.0b4.jar). Can
anyone please take a look at this test case and give any guidance on
how to find and fix the problem?

PS: If anyone wants, I can send the above 3 jar files by email to make
it easier for you to run the below testcase.

Thank you,
Hari



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

Re: FileSet inside MacroDef causing ClassCastException

[Hari Krishna Dara]

From: Mathieu Champlon <[EMAIL PROTECTED]>
To: Ant Developers List 
Date: Wed, 23 Aug 2006 14:50:20 +0900
Subject: Re: FileSet inside MacroDef causing ClassCastException
Hello !

Hari Krishna Dara a écrit :
> Can anyone provide any help in working around or fixing this problem?

It looks like the same bug as
http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?

> Here is the macro that causes trouble (I stripped the sequence to the
> least that causes theis problem, but as I said before, I couldn't copy
> this into a standalone build file and reproduce the exception):
>
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>
> Here is the macro that is part of the same build file and works fine:
>
>   
>   
>   
>   
>   
>   
>   
>   
>   
>property="@{componentName}NeedsPatchTmp"
>   refid="patchfileset"/>
>   
>   
>arg2=""/>
>   
>   
>   
>   
How are your macro called ? With what 'selection' ?
How many times each ? In which order ?
What happens when you remove the call to the 'working' one ? (I suspect
it 'fixes' the other :p)

I'm not really surprised by the fact that it works fine when you copy
your macros to a new build file, I had quite a lot of fun trying to
reproduce the bug for the issue :)
Actually what happens is that the same element is used either in several
macros or several times in the same macro. Then as it gets resolved (and
so is not an unknown element anymore) upon first use, it is no longer an
UnknownElement for the remaining calls...
I don't know if this makes sense, but anyway try and apply the patch and
see if it fixes this issue for you ?

MAT.


I tried the patch suggested in the bug report on 1.6.2, but that
didn't solve the problem. So I applied the patch to 1.6.5 version, but
still I got the same exception. However, I was able to verify that the
patch fixes the testcase that you attached (by running before and
after applying the patch).

Just like you guessed, if I comment the lines that are working, the
next two calls to this macro including the one that was failing
before, go through fine. This probably indicates that the problem you
reported and this are related, but there is still another case that is
not taken care of?

Based upon your test case, and more trial and error of carefully
commenting parts of the code, I narrowed down the macrodef's that are
causing this problem. I am pasting a reproducible test case below, but
it requires BeanShell/BSF jar files to be present in the classpath/ant
lib directory (bsf.jar, bsh-2.0b4.jar and bsh-bsf-2.0b4.jar). Can
anyone please take a look at this test case and give any guidance on
how to find and fix the problem?

PS: If anyone wants, I can send the above 3 jar files by email to make
it easier for you to run the below testcase.

Thank you,
Hari




   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   
   

DO NOT REPLY [Bug 40300] - Copying with filterset a file containing non ascii characters brings strange error message

[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=40300


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |1.7




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 18:13 ---
the root cause looks like the Malformed exception didnt have any text

we should have it that wherever BuildException is formed from a nested
exception, if that nested fault has no error text, we at least copy in the full
classname of the nested fault.

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

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

DO NOT REPLY [Bug 38732] - rmic task doesn't work with -Xnew and JDK 6.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=38732





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 18:11 ---
no, you'd go

  
  

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

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

release message for the beta

[Antoine Levy-Lambert]

Hi,

in the past I have always improvised the text of the release messages.

Does anyone have suggestions about what to say about ant 1.7.

I would write :

Ant 1.7 introduces a resource framework. Some of the core ant tasks such as 
 are now able to process not only file system resources but also zip 
entries, tar entries, ... Resource collections group resources, and can be 
further combined with operators such as union and intersection. This can be 
extended by custom resources and custom tasks using resources.

Ant 1.7 fixes also a large number of bugs.

Regards,

Antoine


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

DO NOT REPLY [Bug 40300] - Copying with filterset a file containing non ascii characters brings strange error message

[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=40300


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Message not helpful |Copying with filterset a
   ||file containing non ascii
   ||characters brings strange
   ||error message




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

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

DO NOT REPLY [Bug 40300] - Message not helpful

[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=40300





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 15:11 ---
Output from ant --noconfig -debug -verbose -f test.xml:

ANT_HOME=/opt/apache-ant-1.6.5/
Apache Ant version 1.6.5 compiled on June 2 2005
Apache Ant version 1.6.5 compiled on June 2 2005
Buildfile: test.xml
Adding reference: ant.PropertyHelper
Detected Java version: 1.4 in: /opt/IBMJava2-142/jre
Detected OS: Linux
Adding reference: ant.ComponentHelper
Setting ro project property: ant.version -> Apache Ant version 1.6.5 compiled on
June 2 2005
Setting ro project property: ant.file -> /home/bpracht/test.xml
Adding reference: ant.projectHelper
Adding reference: ant.parsing.context
Adding reference: ant.targets
parsing buildfile /home/bpracht/test.xml with URI = 
file:///home/bpracht/test.xml
Setting ro project property: ant.project.name -> Test
Adding reference: Test
Setting ro project property: ant.file.Test -> /home/bpracht/test.xml
Project base dir set to: /home/bpracht
 +Target: 
 +Target: test
Attempting to create object of type org.apache.tools.ant.helper.DefaultExecutor
Adding reference: ant.executor
Build sequence for target(s) `test' is [test]
Complete build sequence is [test, ]

test:
Could not load a dependent class (com/sun/media/jai/codec/FileSeekableStream)
for type image
Could not load a dependent class (com/jcraft/jsch/UserInfo) for type sshexec
Could not load a dependent class (com/jcraft/jsch/UserInfo) for type scp
Could not load a dependent class (jdepend/xmlui/JDepend) for type jdepend
Could not load a dependent class (junit/framework/TestListener) for type junit
fileset: Setup scanner in dir /home/bpracht/testin with patternSet{ includes:
[FilteredFile.txt] excludes: [] }
 [copy] FilteredFile.txt added as FilteredFile.txt doesn't exist.
 [copy] Copying 1 file to /home/bpracht/testout
 [copy] Copying /home/bpracht/testin/FilteredFile.txt to
/home/bpracht/testout/FilteredFile.txt

BUILD FAILED
/home/bpracht/test.xml:8: Failed to copy /home/bpracht/testin/FilteredFile.txt
to /home/bpracht/testout/FilteredFile.txt due to null
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:637)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:430)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java(Compiled Code))
at 
sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287)
at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223)
at java.io.InputStreamReader.read(InputStreamReader.java:208)
at java.io.BufferedReader.fill(BufferedReader.java:153)
at java.io.BufferedReader.read(BufferedReader.java:174)
at 
org.apache.tools.ant.util.LineTokenizer.getToken(LineTokenizer.java:60)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:564)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:330)
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:626)
... 13 more
--- Nested Exception ---
sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java(Compiled Code))
at 
sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287)
at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223)
at java.io.InputStreamReader.read(InputStreamReader.java:208)
at java.io.BufferedReader.fill(BufferedReader.java:153)
at java.io.BufferedReader.read(BufferedReader.java:174)
at 
org.apache.tools.ant.util.LineTokenizer.getToken(LineTokenizer.java:60)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:564)
   

DO NOT REPLY [Bug 40300] - Message not helpful

[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=40300





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 15:09 ---
Output from ant --noconfig -debug -f test.xml:

ANT_HOME=/opt/apache-ant-1.6.5/
Apache Ant version 1.6.5 compiled on June 2 2005
Buildfile: test.xml
Adding reference: ant.PropertyHelper
Detected Java version: 1.4 in: /opt/IBMJava2-142/jre
Detected OS: Linux
Adding reference: ant.ComponentHelper
Setting ro project property: ant.version -> Apache Ant version 1.6.5 compiled on
June 2 2005
Setting ro project property: ant.file -> /home/bpracht/test.xml
Adding reference: ant.projectHelper
Adding reference: ant.parsing.context
Adding reference: ant.targets
parsing buildfile /home/bpracht/test.xml with URI = 
file:///home/bpracht/test.xml
Setting ro project property: ant.project.name -> Test
Adding reference: Test
Setting ro project property: ant.file.Test -> /home/bpracht/test.xml
Project base dir set to: /home/bpracht
 +Target: 
 +Target: test
Attempting to create object of type org.apache.tools.ant.helper.DefaultExecutor
Adding reference: ant.executor
Build sequence for target(s) `test' is [test]
Complete build sequence is [test, ]

test:
Could not load a dependent class (com/sun/media/jai/codec/FileSeekableStream)
for type image
Could not load a dependent class (com/jcraft/jsch/UserInfo) for type sshexec
Could not load a dependent class (com/jcraft/jsch/UserInfo) for type scp
Could not load a dependent class (jdepend/xmlui/JDepend) for type jdepend
Could not load a dependent class (junit/framework/TestListener) for type junit
fileset: Setup scanner in dir /home/bpracht/testin with patternSet{ includes:
[FilteredFile.txt] excludes: [] }
 [copy] FilteredFile.txt added as FilteredFile.txt doesn't exist.
 [copy] Copying 1 file to /home/bpracht/testout
 [copy] Copying /home/bpracht/testin/FilteredFile.txt to
/home/bpracht/testout/FilteredFile.txt

BUILD FAILED
/home/bpracht/test.xml:8: Failed to copy /home/bpracht/testin/FilteredFile.txt
to /home/bpracht/testout/FilteredFile.txt due to null
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:637)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:430)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java(Compiled Code))
at 
sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287)
at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223)
at java.io.InputStreamReader.read(InputStreamReader.java:208)
at java.io.BufferedReader.fill(BufferedReader.java:153)
at java.io.BufferedReader.read(BufferedReader.java:174)
at 
org.apache.tools.ant.util.LineTokenizer.getToken(LineTokenizer.java:60)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:564)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:330)
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:626)
... 13 more
--- Nested Exception ---
sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java(Compiled Code))
at 
sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287)
at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223)
at java.io.InputStreamReader.read(InputStreamReader.java:208)
at java.io.BufferedReader.fill(BufferedReader.java:153)
at java.io.BufferedReader.read(BufferedReader.java:174)
at 
org.apache.tools.ant.util.LineTokenizer.getToken(LineTokenizer.java:60)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:564)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils

svn commit: r434056 - in /ant/core/trunk: fetch.xml lib/libraries.properties

[stevel]

Author: stevel
Date: Wed Aug 23 07:52:58 2006
New Revision: 434056

URL: http://svn.apache.org/viewvc?rev=434056&view=rev
Log:
update jsch version.

I'd move to xerces 2.8.0 if there was a consistent release of the api and impl 
artifacts, as it is 2.6.2 is the one to use.

Modified:
ant/core/trunk/fetch.xml
ant/core/trunk/lib/libraries.properties

Modified: ant/core/trunk/fetch.xml
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/fetch.xml?rev=434056&r1=434055&r2=434056&view=diff
==
--- ant/core/trunk/fetch.xml (original)
+++ ant/core/trunk/fetch.xml Wed Aug 23 07:52:58 2006
@@ -135,7 +135,7 @@
 description="load networking libraries (commons-net; jsch)"
 depends="init">
 
-
+
   
 
   http://svn.apache.org/viewvc/ant/core/trunk/lib/libraries.properties?rev=434056&r1=434055&r2=434056&view=diff
==
--- ant/core/trunk/lib/libraries.properties (original)
+++ ant/core/trunk/lib/libraries.properties Wed Aug 23 07:52:58 2006
@@ -25,7 +25,7 @@
 jdepend.version=2.7
 jruby.version=0.8.3
 junit.version=3.8.2
-jsch.version=0.1.25
+jsch.version=0.1.27
 jython.version=2.1
 log4j.version=1.2.13
 #rhino.version=1.5.4R1



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

svn commit: r434055 - /ant/core/trunk/lib/libraries.properties

[stevel]

Author: stevel
Date: Wed Aug 23 07:47:45 2006
New Revision: 434055

URL: http://svn.apache.org/viewvc?rev=434055&view=rev
Log:
move up to maven 2.0.4

Modified:
ant/core/trunk/lib/libraries.properties

Modified: ant/core/trunk/lib/libraries.properties
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/lib/libraries.properties?rev=434055&r1=434054&r2=434055&view=diff
==
--- ant/core/trunk/lib/libraries.properties (original)
+++ ant/core/trunk/lib/libraries.properties Wed Aug 23 07:47:45 2006
@@ -2,14 +2,14 @@
 #a given release of the components
 
 #if you change this, change the checksum to match
-m2.version=2.0.1
+m2.version=2.0.4
 m2.url=http://ibiblio.org/maven2/
 m2.artifact-name=maven-artifact-ant
 m2.jar.name=${m2.artifact-name}-${m2.version}-dep.jar
 #this is the URL of the antlib library, that is pulled down for everything 
else.
 
m2.antlib.url=${m2.url}/org/apache/maven/${m2.artifact-name}/${m2.version}/${m2.jar.name}
 #this is the sha1 checksum of the artifact
-m2.sha1.checksum=7240828f1744c1f9f8b158a026ac368a03f536a3
+m2.sha1.checksum=4e7ddfdb91600e9b59bb965ff8eef2f06015df50
 
 
 #versions of different libraries. Please keep in alphabetical order, except



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

Re: Can DefaultLogger record the time on each target transition?

[Paul Hammant]

Jeffrey,



In addition to backwards compatibility, there are other issues to  
consider:


1) Granularity: why limit timing data to targets? why not extend it  
to tasks as well?


Personally, I'm not interested in timing tasks. Perhaps that could be  
debated another time.



2) Filtering: do you want timing data for every target? every task?


As above. I'm interested for this (closing) discussion to consider  
target only, not task. Also, this proposal is asking for the a "time  
since start of build" not "total time taken for target, start to  
finish".  Specifically, the time when the target starts, not the time  
when the target ends.





and the big one

3) Multithreading: as the committers on this list will tell you,  
I'm always thinking about this one. At IBM, we use Ant + in-house  
antlibs to build the WebSphere family of products. We're fortunate  
to have very good hardware in our build lab, and with products as  
large as WebSphere we're keen on making the most efficient use of  
it; one of the ways we do that is to multithread our builds. In our  
initial experiments we wanted to get timing data to compare against  
our single-threaded builds, so we wrote our own custom logger (just  
slight changes to the default logger) to print the timings. When we  
ran the builds, everything went haywire.




I see how multithreading would affect a strategy to collect timings.  
Again though I'm asking for something else.


---

I think however I I'll let this drop now. There's enough weight of  
opinion against the change for it to obviously futile to carry on. No  
consensus is emerging.


Have fun,

- Paul

DO NOT REPLY [Bug 28514] - Ant 1.6.1 and weblogic 8.1 ant tasks

[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=28514


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:52 ---
This sounds like a weblogic problem, or how they load classes. 

marking as wontfix. 



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

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

DO NOT REPLY [Bug 38732] - rmic task doesn't work with -Xnew and JDK 6.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=38732





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:50 ---
(In reply to comment #16)
> Robert, when ant1.7 appears in beta form next week, can you download it and 
> see
> if the xnew adapter meets your needs?

Sure thing, do you mean I should replace
  

...
  
with
  
...
  
?

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

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

DO NOT REPLY [Bug 34936] - java.io.IOException: cvs: not found when calling ant from crontab

[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=34936


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:50 ---
Stefan, is this still a problem? I'm going to close it as worksforme, because
its a cron setup problem, not ant.

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

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

DO NOT REPLY [Bug 35887] - ExitException exitcode is lost

[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=35887


[EMAIL PROTECTED] changed:

   What|Removed |Added

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




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:48 ---
Ant 1.7beta 1 will pass the exception up stream, so if you explicitly catch an
ExitException() you can get at the exit code.

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

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

DO NOT REPLY [Bug 37618] - APT task fails with too many files

[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=37618


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:47 ---
yes, it should be fixed in ant1.7 beta 1. reopen if not.

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

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

DO NOT REPLY [Bug 16604] - Java task classpath problems on JDK 1.2 and Windows 9x

[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=16604





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:42 ---
Assuming this is Win9x only, and as win9x is not supported in ant1.7, I'm
tempted to mark this as wontfix. 

I have one worry: what happens on Winnt in the same environment?

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

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

Re: Use of reflection in DirectoryScanner to remove duplicated code

[Antoine Levy-Lambert]

On Aug 23, 2006, at 7:26 AM, Kev Jackson wrote:


Hi,

I want to run this by people here to see what people think of  
this.  Basically DirectoryScanner has some duplicated code  
[ accountForIncludedFile, accountForIncludedDir ], I think I have a  
refactored processIncluded method that can replace the duplication,  
but it relies on using Reflection to get access to the classes  
fields and then does the work [1].  I know a lot of Java developers  
are a little leary about using reflection in general as it has a  
reputation for being slow and obtuse, so I'd like to see what you  
guys think before committing something that will be veto'd.


Thanks,
Kev

[1]

Hi Kev,

I know that code duplication is not nice, but I am +0 on this because  
using reflection makes code analysis tools not do their work  
correctly. If you do for instance a method call graph in an IDE,  
methods called by reflection will not be displayed.


I prefer code which is more lengthy but readable.

If we had a solution to remove this duplication by using classes/ 
interfaces I would find it neater.


Just my 2 cents.

Antoine

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

DO NOT REPLY [Bug 15567] - weblogic deploy

[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=15567


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:40 ---
Maria? Is this still a problem? And is it ant related or web logic related? Can
you add a build file?

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

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

DO NOT REPLY [Bug 38732] - rmic task doesn't work with -Xnew and JDK 6.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=38732


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:35 ---
closing as fixed; if it isnt, feel free to reopen it.

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

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

DO NOT REPLY [Bug 38732] - rmic task doesn't work with -Xnew and JDK 6.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=38732





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 12:34 ---
Ok. committed a new xnew compiler that works on java1.5; not tested on java1.6

Robert, when ant1.7 appears in beta form next week, can you download it and see
if the xnew adapter meets your needs?

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

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

svn commit: r434030 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java

[stevel]

Author: stevel
Date: Wed Aug 23 05:36:46 2006
New Revision: 434030

URL: http://svn.apache.org/viewvc?rev=434030&view=rev
Log:
bug ID#38732 , rmic task doesn't work with -Xnew and JDK 6.0

Fixed by writing a new adapter, xnew, that extends the forking adapter and sets 
the -Xnew argument. Tests supplied, though the old test, the one that would 
fail on java1.6, is still there.

Also made the name matching code of rmic locale-independent.

Added:
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java

Added: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java?rev=434030&view=auto
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java 
(added)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/XNewRmic.java 
Wed Aug 23 05:36:46 2006
@@ -0,0 +1,33 @@
+package org.apache.tools.ant.taskdefs.rmic;
+
+import org.apache.tools.ant.types.Commandline;
+
+/**
+ * Run rmic in a new process with -Xnew set.
+ * This switches rmic to use a new compiler, one that doesnt work in-process
+ * on ant on java1.6 
+ * @see: http://issues.apache.org/bugzilla/show_bug.cgi?id=38732
+ */
+public class XNewRmic extends ForkingSunRmic {
+
+/**
+ * the name of this adapter for users to select
+ */
+public static final String COMPILER_NAME = "xnew";
+
+public XNewRmic() {
+}
+
+/**
+ * Create a normal command line, then with -Xnew at the front
+ * @return a command line that hands off to thw
+ */
+protected Commandline setupRmicCommand() {
+String options[]=new String[] {
+"-Xnew"
+};
+Commandline commandline = super.setupRmicCommand(options);
+return commandline;
+}
+
+}



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

svn commit: r434029 - in /ant/core/trunk: ./ docs/manual/CoreTasks/ src/etc/testcases/taskdefs/rmic/ src/main/org/apache/tools/ant/taskdefs/rmic/ src/testcases/org/apache/tools/ant/taskdefs/

[stevel]

Author: stevel
Date: Wed Aug 23 05:36:25 2006
New Revision: 434029

URL: http://svn.apache.org/viewvc?rev=434029&view=rev
Log:
bug ID#38732 , rmic task doesn't work with -Xnew and JDK 6.0

Fixed by writing a new adapter, xnew, that extends the forking adapter and sets 
the -Xnew argument. Tests supplied, though the old test, the one that would 
fail on java1.6, is still there.

Also made the name matching code of rmic locale-independent.

Modified:
ant/core/trunk/WHATSNEW
ant/core/trunk/docs/manual/CoreTasks/rmic.html
ant/core/trunk/src/etc/testcases/taskdefs/rmic/rmic.xml

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/RmicAdapterFactory.java

ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/RmicAdvancedTest.java

Modified: ant/core/trunk/WHATSNEW
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=434029&r1=434028&r2=434029&view=diff
==
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Wed Aug 23 05:36:25 2006
@@ -71,6 +71,8 @@
   IE (Windows) or Gnome2 (Unix/Linux) proxy settings. This may break any build
   file that somehow relied on content outside the firewall being unreachable:
   use the -noproxy command-line option to disable this new feature.
+  Note that the Java1.5 proxy configuration system still does not appear to 
work 
+  reliably on Windows or Linux.
 
 * A bug in SQLExec would prevent the execution of trailing,
   non-semicolon-delimited statements.  Bugzilla Report 37764.
@@ -97,7 +99,7 @@
 * Ant launcher program prints errors to stderr, and exits with a 2 exit code
   value if, for any reason, it cannot actually start Ant proper. This will only
   affect programs/scripts that called the launcher and which did not want to
-  receive an error if ant itself would not start
+  receive an error if Ant itself would not start
 
 Fixed bugs:
 ---
@@ -264,6 +266,9 @@
 * The  API allowed creation of directories in file-only archives; a
   habitual offender was the subclassed , which included META-INF/ in
   the destination file regardless of whether filesonly was set to true.
+  
+*  has a new adapter, xnew, to use the -XNew back end on java1.5+.
+  By forking rmic, this works on java1.6+. Bugzilla report 38732.
 
 Other changes:
 --
@@ -271,7 +276,7 @@
 * InputHandler implementations may now call InputRequest.getDefaultValue()
   if they wish. The default handler uses this also. Bugzilla report 28621.
 
-* Took in bugzilla report 39320.
+* Took in bugzilla report 39320, "Simple code cleanups"
 
 * Improve compatibility with GNU Classpath and java versions prior to 1.5. 
Bugzilla 39027.
 

Modified: ant/core/trunk/docs/manual/CoreTasks/rmic.html
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/docs/manual/CoreTasks/rmic.html?rev=434029&r1=434028&r2=434029&view=diff
==
--- ant/core/trunk/docs/manual/CoreTasks/rmic.html (original)
+++ ant/core/trunk/docs/manual/CoreTasks/rmic.html Wed Aug 23 05:36:25 2006
@@ -40,8 +40,11 @@
   sun (the standard compiler of the JDK)
   kaffe (the standard compiler of http://www.kaffe.org"; 
target="_top">Kaffe)
   weblogic
-  forking - the sun compiler forked into a separate process
-   "" (empty string). This has the same behaviour as not setting the 
compiler attribute.
+  forking - the sun compiler forked into a separate process (since Ant 
1.7)
+  xnew - the sun compiler forked into a separate process,
+  with the -Xnew option (since Ant 1.7).
+  This is the most reliable way to use -Xnew
+ "" (empty string). This has the same behaviour as not setting the 
compiler attribute.
 First the value of build.rmic is used if defined, and if not, the 
default
 for the platform is chosen. If build.rmic is set to this, you get the 
default.
 
@@ -83,7 +86,9 @@
 stubversion
 Specify the JDK version for the generated stub code.
  Specify "1.1" to pass the "-v1.1" option to rmic,
- "1.2" for -v12, compat for -vcompat. 
+ "1.2" for -v12, compat for -vcompat. 
+Since Ant1.7, if you do not specify a version, and do not ask
+for iiop or idl files, "compat" is selected.
  
  
 No, default="compat"
@@ -245,7 +250,7 @@
 ${build}/classes.
 
 
-Copyright © 2000-2005 The Apache Software Foundation. 
All rights
+Copyright © 2000-2006 The Apache Software Foundation. 
All rights
 Reserved.
 
 

Modified: ant/core/trunk/src/etc/testcases/taskdefs/rmic/rmic.xml
URL: 
http://svn.apache.org/viewvc/ant/core/trunk/src/etc/testcases/taskdefs/rmic/rmic.xml?rev=434029&r1=434028&r2=434029&view=diff
==
--- ant/core/trunk/src/etc/testcases/taskdefs/rmic/rmic.xml (original)
+++ ant/core/trunk/src/etc/testcases/taskdefs/rmic/rmic.xml Wed Aug 23 05:36:25 
2006

Re: [Vote promote ant-vss antlib to antlibs proper] result/summary

[Antoine Levy-Lambert]

On Aug 23, 2006, at 7:42 AM, Kev Jackson wrote:



On 23 Aug 2006, at 10:57, Stefan Bodewig wrote:


On Wed, 23 Aug 2006, Kev Jackson <[EMAIL PROTECTED]> wrote:


With the 1.7.0 beta scheduled for the next few days, I'd like to
resolve some of the peripheral issues, and if the consensus is to
drop the optional vss task from the 1.7.0 release, I for one won't
shed any tears at it's passing.


We can't drop them from this release as long as the VSS Antlib is in
the sandbox.  Users wouldn't have an alternative since the Antlib
wouldn't see a release anytime soon.


I agree, that's why I'd like to promote the antlib from the sandbox  
and

drop the optional task at the same time.  The thing holding the antlib
in the sandbox is simple the lack of committers (AFAIK).

I think we should bend the rule and move the VSS antlib out of the  
sandbox with just two committers.

Regards,
Antoine


kev

--
"All governments are in equal measure good and evil.  The best  
ideal is anarchy." - Leo Tolstoy






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

Re: [site] Separate svn directoy for WebSite?

[Antoine Levy-Lambert]

On Aug 23, 2006, at 7:44 AM, Stefan Bodewig wrote:


Hi,


...

What it doesn't contain right now are the static files that are
directly inside of the ./docs directory.  The easiest solution would
be to move them to ./xdocs in core and copy them to ./docs in core and
./generated in site.


this sounds like a rationalization/unification measure so +1

Any comments - including "stop that"?
+1 just make sure to write a cheat sheet so that everybody  
understands the process to update the site.


Stefan


Regards

Antone

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

Re: classloader for 1.7

[Antoine Levy-Lambert]

Hello Peter,

I have just had a look at the link provided. It looks powerful.
Cool that it already has documentation.

Regards,

Antoine

On Aug 23, 2006, at 2:26 PM, Peter Reilly wrote:


The one in 1.6 does not work.
The proposed one is totally different.
see http://enitsys.sourceforge.net/ant-classloadertask/

Peter

On 8/23/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:


On Tue, 22 Aug 2006, Peter Reilly <[EMAIL PROTECTED]>  
wrote:


> If it is not a little too late, I would like to get a vote on
> including classloader into ant 1.7.

It has been included since 1.6.0 we just never told anybody.  Or is
the one you want any different from the classloader task that is
already part of the code base.

Basically the task only needs documentation.  I'm not against
documenting it as long as the documentation contains a warning that
you might shoot yorself in the foot.

Stefan




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

DO NOT REPLY [Bug 38732] - rmic task doesn't work with -Xnew and JDK 6.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=38732





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 11:51 ---
If we look at the rmic source

http://www.cs.duke.edu/csed/java/source1.5/src/share/classes/sun/rmi/rmic/Main.java

we can see that -xnew triggers a load+invoke of sun.rmi.rmic.newrmic.Main,
completely bypassing the other bits.

What we could do is have a new compiler adapter "xnew" that 
 -uses this as the entry point (or runs classic rmic with -Xnew)
 -forks on all java versions
This would eliminate the need to look for -XNew as an argument to rmic itself,
and make management of the problem much less contrived (the alternate is to
check for sun && java1.6+ && -XNew in the argument list and switch to the
forking compiler)

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

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

Re: classloader for 1.7

[Peter Reilly]

Yes, classloader issues do give me headaches.

I see a number of use cases for the classloader task;

1) stop the need to do add third-party jars to ~/.ant/lib for
   the ant optional tasks.
   This could be avoided if all the optional task are converted a la junit,
   but that would be a big job.

2) allow build files to specify the lib directories to seach for
classes/tasks
   placing this on the command line is very offputting.

The antlibs solution would be ok, but it does not solve ant optional tasks
or
issues like the script task needing language specific jar files. Each of
these may be solved independently, but this means that each type of
classloader problem would be solved differently - hard to understand and
remember.

Peter

On 8/23/06, Jesse Glick <[EMAIL PROTECTED]> wrote:


Peter Reilly wrote:
> If it is not a little too late, I would like to get a vote
> on including classloader into ant 1.7.

+0.5 I guess, if someone is testing it carefully (URLClassLoaderAdapter
in particular is a little unnerving). Really the advantage #1,

"to avoid the need to either change Ant's default installation by adding
or removing jars to or from Ant's lib dir or manage the classpath in the
launching script"

is a workaround for Ant's inability to autoload antlibs from a defined
classpath. Would be better to be able to say e.g.


   
 
   


   


where the  call just registers a fileset (or, internally,
ClassLoader) and any later attempt to use a namespace automatically
checks for a matching antlib.xml, without touching the startup class
loader. It's a problem in Ant core that it cannot autodetect antlibs
except in Ant's startup loader.

Another issue is just that people are often intimidated by
ClassLoader's: they work logically once you get it, but getting it is
like math homework. Exposing a  task for widespread
consumption may make Ant seem for "experts only". Of course you don't
have to use the task if you don't want to, but what if we don't fix the
usability problems that made the task necessary to begin with, and using
 starts to be considered normal for Ant scripts?

-J.

--
[EMAIL PROTECTED]  x22801  netbeans.org  ant.apache.org
   http://google.com/search?q=e%5E%28pi*i%29%2B1


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

Re: classloader for 1.7

[Peter Reilly]

The one in 1.6 does not work.
The proposed one is totally different.
see http://enitsys.sourceforge.net/ant-classloadertask/

Peter

On 8/23/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:


On Tue, 22 Aug 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:

> If it is not a little too late, I would like to get a vote on
> including classloader into ant 1.7.

It has been included since 1.6.0 we just never told anybody.  Or is
the one you want any different from the classloader task that is
already part of the code base.

Basically the task only needs documentation.  I'm not against
documenting it as long as the documentation contains a warning that
you might shoot yorself in the foot.

Stefan

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

DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs

[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=40152


[EMAIL PROTECTED] changed:

   What|Removed |Added

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




--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 10:40 ---
Fixed in SVN_HEAD, with tests. Please check the 1.7beta when it comes out.

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

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

DO NOT REPLY [Bug 40300] - Message not helpful

[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=40300





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 09:32 ---
also, what does a -verbose or -debug run return. It could be that we are
catching a File io exception which doesnt have an explanation string.

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

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

DO NOT REPLY [Bug 40291] - classpath uses colon, ":", as path separator under windows

[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=40291





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 09:27 ---
Ant does allow : as a path separator in a spec string, how else would we be
cross platform? We do, however, downconver it to the platform specific value at
runtime, with special handling for c: paths on windows, and something else on
netware.

But remember that everything is a string unless ant knows to convert it to a
native platform. So if you work in the string-space, ant is not going to do any
work. This is what you are doing with your args to tinyvm




you should use



to get stuff converted.

Try this, if the problem goes away, please mark the bug as invalid.

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

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

[EMAIL PROTECTED]: Project svn-antlib-test (in module ant-antlibs) failed

[Gump Integration Build]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project svn-antlib-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 43 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- svn-antlib-test :  Task and Type Libraries for Apache Ant


Full details are available at:
http://vmgump.apache.org/gump/public/ant-antlibs/svn-antlib-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant-testutil exists, no need to add for property 
ant-testutil.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/ant-antlibs/svn-antlib-test/gump_work/build_ant-antlibs_svn-antlib-test.html
Work Name: build_ant-antlibs_svn-antlib-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 mins 25 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dant-testutil.jar=/usr/local/gump/public/workspace/ant/build/lib/ant-testutil.jar
 test 
[Working Directory: /usr/local/gump/public/workspace/ant-antlibs/svn]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant-antlibs/svn/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-testutil.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/ant-antlibs/svn/build/ant-svn-23082006.jar
-
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:164)
[junit] at junit.framework.TestCase.runBare(TestCase.java:130)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit] at junit.framework.TestResult.run(TestResult.java:113)
[junit] at junit.framework.TestCase.run(TestCase.java:120)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:228)
[junit] at junit.framework.TestSuite.run(TestSuite.java:223)
[junit] at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:361)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:809)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:648)

[junit] Testcase: testDiffWithImplicitTrunk took 65.298 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError: null
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at junit.framework.Assert.assertTrue(Assert.java:20)
[junit] at junit.framework.Assert.assertTrue(Assert.java:27)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.assertModified(SvnTagDiffTest.java:109)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.assertDiffWithTrunk(SvnTagDiffTest.java:62)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.testDiffWithImplicitTrunk(SvnTagDiffTest.java:56)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:164)
[junit] at junit.framework.TestCase.runBare(TestCase.java:130)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[jun

Re: Use of reflection in DirectoryScanner to remove duplicated code

[Kev Jackson]

Hi Stefan, (and other interested devs)

For additional testing I've created a directory/file structure like

1/
  1 2/
   2 3/
3 4/

ie a single file under a directory, the tree is 1038+ layers deep and  
there is no difference between the original time taken by the  
DirectoryScanner code and the modified code - if you want more  
testing of this I'm willing to accommodate, but I'm pretty sure that  
the Java reflection == slow is not always the case, and certainly  
isn't in this case.  I agree we must be careful to prevent new code  
from causing the system to 'appear' slow (perceived performance), but  
in this instance, I cannot prove that it is faster/slower, any  
differences are minor (10s of milliseconds).


As an aside, my little recursive script to generate a mad dir  
structure for testing breaks some kind of limit (unix or ruby not  
sure) for file names, so any additional testing would require a  
different script to generate the directory structure first :)


Kev

--
"In vain you tell me that Artificial Government is good, but that I  
fall out with the Abuse. The Thing! The Thing itself is the Abuse!" -  
Edmund Burke



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

Re: Use of reflection in DirectoryScanner to remove duplicated code

[Kev Jackson]

On 23 Aug 2006, at 11:38, Stefan Bodewig wrote:


On Wed, 23 Aug 2006, Kev Jackson <[EMAIL PROTECTED]> wrote:


I want to run this by people here to see what people think of this.
Basically DirectoryScanner has some duplicated code [
accountForIncludedFile, accountForIncludedDir ], I think I have a
refactored processIncluded method that can replace the duplication,
but it relies on using Reflection to get access to the classes
fields and then does the work [1].


Please run some tests on really large directory trees,
DirectoryScanner is probably the class with the biggest impact on
perceived Ant performance.  We shouldn't do anything that makes it
significantly slower.


Ok, well I've just run the DirectoryScannerTest embedded in eclipse  
JUnit runner, and there is no difference in performance at all  
between using the original code and the modified code


original 2.778 seconds to run 27 tests
modified 2.734 seconds to run 27 tests

This is using Suns jsdk 1.5.  I'm not sure how I can test using  
'really large directory trees'.  The modified code is only run inside  
scandir (which I know is a major part of the directory scanner).  I  
guess you worry not about having loads of files, but in the case  
where there is a massively nested directory tree - I'll have to  
create a pathological case to test this though.


Kev
--
"That government is best which governs not at all" - Henry Thoreau


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