1. From my understanding the selector are part of a fileset, but in a fileset the dir attribute is mandatory and point only to one directory. So is really a selector the appropriate choice?
Right. But you can always use a common parent dir, and later use filename mappers. This does assume that the dirs have a common ancestor, which was my case. I don't have an example use of this selector to show (at least no right now), but I vaguely remember I used a <dirset> somewhere.
2. From the code the selector create a lot of other selector (one per directory) is it really the best thing to do? I mean in the performance point of view?
Not really. This code was used against a large file hierarchy (the result of compiling 5000+ java sources, so probably upward of 10K+ files), and it was not that slow. Just traversing that many files is slow by itself in Java ;-) But sure, I simply used the easiest path, which is to reuse as much code as possible. That's a none-trivial selector in very few lines of code ;-)
3. Won't you use resource instead of selector? This seems very simetric to the javaresource (instead of class I'm searching files)
Not sure I'm following here. In any case, I simply supplied example code that provided quick scaffolding to write a selector made of other selectors, complementing Stefan's answer. In your case, you must have an explicit list of pseudo-patterns, in the sense that they are not "patterns" but relative and resolved filenames. If the files are really coming from unrelated dirs, then you cannot gather them in a <fileset>, which requires a basedir. You can only use a <filelist> I guess. And a filelist requires explicit absolute filenames. --DD If you have an explicit list of patterns to look for, writting a <script> or a task ma --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
