ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Multiple patternsets in a fileset
Date Mon, 18 Feb 2002 08:31:41 GMT
From: "Erik Hatcher" <>

> From: "Jose Alberto Fernandez" <>
> > 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:   <>
For additional commands, e-mail: <>

View raw message