On Jul 15 2003, [EMAIL PROTECTED] wrote : >I'm not sure I understand what you've done, I'll try to come up with >some unit tests if I think something is wrong 8-)
Please do the unit tests. I also added 3 unit tests to DirectoryScannerTest before checking in my new code. What I did is the following : - create a partition of patterns without wildcards from the include patterns of the fileset, - only start scanning from the patterns in this partition which are not included, - mark the patterns which are files and are included directly as selected files, - mark the patterns which are directories and are included as selected directories, > * You go a long way to avoid redundantly adding patterns in > DirectoryScanner#checkIncludePatterns (the parent check). If the > patterns come in reversed, you'll still have duplicate roots, no? Say > a/b/c is added before a/b is. You may avoid this by sorting the > include patterns first. > True, I will change this tonight > * If all patterns are plain files, i.e. no "pattern" contains any > wildcards, things could still be improved by not performing any > pattern matching at all. > In the current solution, if all patterns are plain files, then there is no scanning, simply the patterns get added to the array includedFiles. > * SelectorUtils#rtrimWildcardTokens should probably short circuit and > return the original input if the input doesn't contain any wildcards > at all. > Yes, but I am not too concerned about this. > I did a test of scanning speed on filesets containing 2 or 3 patterns nested 5 or 6 directories deep, and the new solution is much faster. But scanning time is just unfortunately a small fraction of the time needed to make a jar or a zip file. Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
