From: "Erik Hatcher" <[EMAIL PROTECTED]>
> From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
>
> > What is exactly what will break on the Datatype? Taking a look at it
> > the only thing that FileSet exposes at the end is a DirectoryScanner.
> > Whose only contract is to tell you:
>
> > 1) Files/Directories that are included and not excluded
> > 2) Files/Directories that were not included
> > 3) Files/Directories that were included but were also excluded
>
> 4) The base directory
>
Yeap, miss that one. But still there is no problem for multiple patterns.
Although it makes it more difficult for asubclass implementing Path.
> > Never in any of the APIs says what is the interpretation of
> included/excluded.
> > So, to consider each patternset of the fileset independently is definitely
> > as valid as anything else.
>
> Ok.... I suppose if its not documented anywhere then its fair game to break,
> but almost assuredly folks are using multiple patternsets within a fileset
> and would get bitten by this change of behavior. I'll let the other
> committers chime in if they feel differently and am currently +0 on this
> change since it seems very useful but we should also consider the impact it
> has.
>
Well, I actually say to add a compatibility attribute: segregatePatterns=false.
Probably a better solution is something like 'mixpatterns="false"' that
apply to patterns inside patterns (and FileSet can define a pattern itself).
> >> For example, why do filesets all have to
> >> be from the same directory tree? Why should I not be able to group all
> >> files that are within a path, for instance, and copy those somewhere or
> >> include them into a .zip easily? At the moment I have to do each one
> >> individually and know each files parent directory. I would *love* to see
> >> this particular thorn removed - but the fileset API simply does not allow
> >> for that.
> >>
>
> > There is no reason why you could not implement a subclass of FileSet
> > that allows passing a Path of places to scan.
>
> Sure there is. DirectoryScanner has this:
>
> public File getBasedir() {
> return basedir;
> }
>
> Lots of code relies on a DirectoryScanner being rooted at this base
> directory. DirectoryScanner makes sense based on its class name. FileSet
> does not (IMO). I think a fileset using a DirectoryScanner is not quite
> right. Certainly its important to make a set of files for a given
> directory, but it should also be possible to group scattered files together
> somehow.
>
Fair enough, you got me there. I could come up with a hack but it may not be
worthed.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
