ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: [Submit] Rounding error with dependency checking in SouceFileScanner.java
Date Fri, 30 Nov 2001 20:51:19 GMT
On Thu, 29 Nov 2001, Stefan Bodewig <bodewig@apache.org> wrote:

 > We have a proposal for "cullers", that would create sets of files
 > based on whatever conditions we can come up with, maybe even with a
 > pluggable mechanism so I can write my own filter.
 >
 > How do you see something like this implemented?  As part of fileset
 > itself or as a task that creates a fileset or ...

To my mind, the right model is as part of fileset. This is part of the
selection process for deciding what a fileset contains, and shouldn't be an
outside task's responsibility at all.

By doing it this way, tasks don't have to code specifically for cullers or any
of the other features a fileset may want to support. Any task that supports
filesets gets the behaviour for free. And I find it hard to imagine a task
where having greater control of the files in a fileset would be a bad thing.

The possible downside to this design that I can think of is that users who
want a dependency check to occur on the eventual destination file (which is
the most common usage, though not the only one) will have to specify that
destination twice, once through the fileset's dependency element and once in
the mapper. They will also have to specify the mapper's type in the dependency
element, since if the files are flattened you'd want to check them that way.
You could get around this by specifying that tasks should pass mappers into
filesets whenever they co-occur, but this feels a bit hackish to me. It is a
solution, though.

As for pluggable filters, I don't have a good feel for that. How do you 
foresee it
working? With an attribute that defines a class to call that implements a
standard interface? A <selectdef> at the project level?

 > It has been talked, but not coded to life.

Perhaps something I could work on, then, if there is general agreement on the
desirability of it.



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