ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: Multiple patternsets in a fileset
Date Mon, 18 Feb 2002 01:01:23 GMT
From: "Erik Hatcher" <jakarta-ant@ehatchersolutions.com>

> From: "Bruce Atherton" <bruce@callenish.com>
> 
> > I'd like to challenge that design. To my mind, it is seriously broken, and
> > saying "It's not a bug, it's a feature" is no answer.
> 
> I don't view it as broken, I just view it as "that is the way it is".
> 
> There are other glaringly difficult issues with other datatypes that cannot
> be resolved in the 1.x codebase.  

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

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.

As for the case of people really using the old behaviour, we can solve that
by having a "segregatePatterns" attribute defaulted to false in ANT1.

You do not even need to change the definition of DirectoryScanner as 
FileSet can return its own subclass with the enhanced interpretation..

> 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.

> > Then test*.class and old*.java are excluded, despite the exclusions being
> > in different patternsets.
> >
> > Not only is this counterintuitive behaviour for the user, it takes away
> > functionality for no good reason.
> 
> Its only counterintuitive if you don't know how a fileset works with
> patternsets.
> 

The meaning of counterintuitive is that its implementation defies what people
would think it should be. So I think you have a circular argument here.

> > Having separation in patternsets gives you this functionality. Then there
> > is the question of what a user would expect. If you were encountering an
> > ant build.xml file for the first time, would you expect old*.java to be
> > excluded? Honestly?
> 
> I know how a fileset works, so yes I would expect that behavior.
> 

OK, maybe I am naive, but is there anyone who writes multiple patterns
expecting them to be mush together at the end? I would think that writing
builds like that will produce incomprenhensible buildfiles.
Can you show me a use case?

> I'm all for you pushing the culler implementation and fighting the current
> design of Ant 1.x. Perhaps there is some happy medium where Ant 1.x behavior
> is not changed but enhanced by your cullers, and in Ant2 a much cleaner,
> extensible implementation is built.
> 

There is much that can be done in ANT1 if we just try to racionalize what is in there.
Take a look at my <antlib> with <roles> proposal. Upto this point, I have managed

to make it backward compatible without that stoping me from changing ANT internals 
to a large extend.

BTW, can some committer commit that changes I posted for the <antlib> proposal?

Thanks in advance,

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message