On Fri, 30 Nov 2001, Bruce Atherton <[EMAIL PROTECTED]> wrote: > 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.
I was not thinking about the tasks that use filesets, but one that creates filesets to be used by other tasks. I guess we could make fileset a task and then there is no difference at all. > 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? See the other thread that came in later about generalized container tasks. Having something like <userselector classname="...."/> would be a way consistent with mappers for example, but a more general solution with a central registry is certainly the future goal. > Perhaps something I could work on, then, if there is general > agreement on the desirability of it. I think there is general agreement, that we need a way to generate sets of files based on criteria other than pattern matching. Peter wanted to put together a list of things that needed experimental work IIRC. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
