On Thu, 29 Nov 2001, Stefan Bodewig <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
