Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Wed, 9 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: > I find this pretty weird, if not dangerous. I don't understand > why we don't just fork the tests all the time Because historically (pre Ant 1.6.2) forking would slow down tests immensily. > But now a test requires the reverse!?

RE: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > On Tue, 8 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > > On a related note, ClasspathUtilsTest is marked as run > > unless running.in.gump . But it (seemingly rightly > > so) fails whenever tests.and.ant.share.classloader is > > true. > > Y

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Tue, 8 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > On a related note, ClasspathUtilsTest is marked as run > unless running.in.gump . But it (seemingly rightly > so) fails whenever tests.and.ant.share.classloader is > true. Yes, just tried with -Djunit.fork="true" and it fails - because

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > There are other tests that rely on being in the same > package, we > exclude them via the tests.and.ant.share.classloader > property. On a related note, ClasspathUtilsTest is marked as run unless running.in.gump . But it (seemingly rightly so) fa

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 07 Mar 2005, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Mon, 7 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: >> I was not aware of this restriction. Can you point to a specific VM >> spec? > > Let me sleep over this ;-)

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 7 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] The "package" a >> class belongs to really is not just the package name, but the pair >> of package name and the classloader that has loaded the class. > > Only when a package is sea

RE: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > The "package" a class belongs to really is not just the package name, > but the pair of package name and the classloader that has loaded the > class. Only when a package is sealed, no? Are you saying that you can't have two classes from the same p

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 7 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: >> Looks like a classloader issue (your test has been loaded from a >> different classloader than the class to test which means they are >> not inside the same package). >> >> There are other tests that rely on being in the same pa

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 7 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > Do these get run by Gump in any way? Yes, in this case tests and classes under test share the same classloader, since they all get loaded with the system classloader. > But I'd still like to know how to run such a test. :) Put build/

RE: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > On Mon, 7 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > > That's what I thought, but the test got: > > > > [junit] java.lang.IllegalAccessError: tried to access > > method org.apache.tools > > .ant.DirectoryScanner.getScannedDirs()Ljava/util/S

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Mon, 7 Mar 2005, Matt Benson > <[EMAIL PROTECTED]> wrote: > > That's what I thought, but the test got: > > > > [junit] java.lang.IllegalAccessError: tried to > access > > method org.apache.tools > > > .ant.DirectoryScanner.getScannedDirs()Ljava/u

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 7 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > That's what I thought, but the test got: > > [junit] java.lang.IllegalAccessError: tried to access > method org.apache.tools > .ant.DirectoryScanner.getScannedDirs()Ljava/util/Set; > from class org.apache.tools.ant.DirectoryScannerTest

RE: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > By popular demand: Do not scan directories if > their contents are > > excluded. Changed scannedDirs from a cache to a > result and added > > a gettor method with a warning in the J

RE: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > By popular demand: Do not scan directories if their contents are > excluded. Changed scannedDirs from a cache to a result and added > a gettor method with a warning in the Javadoc that it was a testing > method only. Cool! Should be a

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Hello Matt, this change could speed up directory scanning very much. Let's see what it is going to do. Cheers, Antoine [EMAIL PROTECTED] wrote: mbenson 2005/03/04 15:41:21 Modified:src/main/org/apache/tools/ant DirectoryScanner.java src/testcases/org/apache/tools/ant Director

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Antoine Levy-Lambert wrote: Sorry, I had some disorder in my ant.jar files, here are real results, which are even much better in terms of speed for the new DirectoryScanner (at least for the fileset containing specific includes) : tests done on nagoya (Solaris) NEW VERSION fileset1 : 117 fileset2 6

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On 23 Jul 2003, <[EMAIL PROTECTED]> wrote: > More problems with case sensitivity Two of the new tests fail on Linux (the *ScanningInsensitive ones), I expect all four to fail on case insensitive filesystems. I'm working on a solution that doesn't (completely) cancel the speed benefit. Stefan

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Tue, 22 Jul 2003, Steve Loughran <[EMAIL PROTECTED]> wrote: > Of course, we will see a speedup on case sensitive file systems, > right? It depends 8-) In situations where all your include patterns start with constants paths, you'll see significant enhancements - no matter whether the filesyst

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Sorry, I had some disorder in my ant.jar files, here are real results, which are even much better in terms of speed for the new DirectoryScanner (at least for the fileset containing specific includes) : tests done on nagoya (Solaris) NEW VERSION fileset1 : 117 fileset2 6813 CVS July 10th 2003 fi

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Steve Loughran wrote : > Of course, we will see a speedup on case sensitive file systems, right? Stefan will probably check in a very very good DirectoryScanner tomorrow, which combines speed and accuracy +10 :-) OK here are the figures : tests done on nagoya.apache.org July 22 13:something PDT

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Antoine Levy-Lambert wrote: Stefan, Maybe using something like findFileCaseInsensitive instead of getCanonicalPath would be better. If we agree that we need to return the exact case on case insensitive filesystems, that is. this seems to be the only solution which preserves the old behavior of D

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Tue, 22 Jul 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > I am afraid that if we use it we are going to lose the benefit of > the optimization, Yes, that's what I see while playing with a solution as well. An alternative that I'm currently testing is a combination of getCanonicalPat

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Stefan, > Maybe using something like findFileCaseInsensitive instead of > getCanonicalPath would be better. If we agree that we need to return > the exact case on case insensitive filesystems, that is. this seems to be the only solution which preserves the old behavior of DirectoryScanner and wo

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On 22 Jul 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > I don't know for sure. Let me see, yep, behavior on MacOS X using > HFS is the same as on Windows. To be more precise: Given the code as it is, testFullPathMatchesCaseSensitive, testFullPathMatchesCaseInsensitive and test2ButCaseInsens

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> OK. But for case-insensitive file systems it doesn't matter, right? > The need for this getCanonicalFile() suppose you are building on Windows a jar file in your build.xml you have the jar file will then contain ALPHA/BETA/BETA.XML and it will make a big difference on UNIX, and it will a

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On 21 Jul 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Your getCanonicalPath fix will not catch the situation for any OS > other than Windows (the way it is coded right now). I don't have a solution apart from "do it for all OSes" and "do it for none". > It will also slow down scanning cons

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Mon, 21 Jul 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > No, the original behavior is the current behavior. OK. But for case-insensitive file systems it doesn't matter, right? > The current test of DirectoryScanner passes with the nightly of July > 10th. Sure. > Then we need to

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

> Your getCanonicalPath fix will not catch the situation for any OS > other than Windows (the way it is coded right now). It will also slow > down scanning considerably, probably to the point that your prior > optimization gets undone. And it would probably break in the presence > of symbolic lin

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Stefan, > after your first patch, getIncludedFiles would return the names like > they appeared in the patterns. I.e. if you matched **/GAMMA.XML and > the file was gamma.xml, you'd get the uppercase version. I think this > may have been the original behavior as well. > No, the original behavior

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Antoine, after your first patch, getIncludedFiles would return the names like they appeared in the patterns. I.e. if you matched **/GAMMA.XML and the file was gamma.xml, you'd get the uppercase version. I think this may have been the original behavior as well. When I played with it to get the c

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

There is a problem here : with a nightly build of ant of July 10th 2003 (before I begun doing my optimizations to DirectoryScanner), DirectoryScanner did not restitute included files and directories according to the case of the include patterns like now, but according the case of the files and dire

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

On Wed, 16 Jul 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > - The other possibility is to write (for instance in FileUtils) a > routine of the type public static File findFileCaseInsensitive(File > basedir, String child) which internally would try all > uppercase/lowercase combinations

Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java

Concerning the case insensitive scanning : - As a very short term fix, one can bypass the checkIncludePatterns routine and call scandir(basedir, "", true) in the case of case insensitive scanning. - The other possibility is to write (for instance in FileUtils) a routine of the type public static