At 08:49 20/3/01 -0500, Eric Siegerman wrote: >On Wed, Mar 21, 2001 at 12:02:38PM +1100, Peter Donald wrote: >> At 07:03 20/3/01 -0500, Eric Siegerman wrote: >> >1. Can I do set arithmetic on FileSet's? >> >> No need to in most cases. >> [suggested alternative deleted] >> Not all tasks support [the alternative] but most that I have needed do. > >That's precisely the point of fileset arithmetic -- to factor >this out in the ant code so that task classes don't need to >*think* about it.
Yes we do intend to provide base utilities that are accessible to all classes. In most cases the task writer don't have to think (or will not in the future). >Consider this a gripe about the lack of orthogonality in task >implementations -- and a suggested (partial?) fix. (Dunno >whether it's a complete fix because I'm too new at ant to know >how unorthogonal the tasks are in the first place. But at worst, >this would be a complete fix for one class of irregularities...) This sort of talk is similar to what has just been discussed recently on ant-dev. Being able to have aspects handled outside the task and then "applied to task". Some possible implementations have been a lisp-like (map function fileitems) or inheritance from base class etc. > >> Multiple >> filesets combined with exclude/include (or patternsets) will work the magic >> you need. > >That's the other point :-) -- to let me factor such similarities >out in my buildfile, so my task calls don't need to think about >it. Not sure what you mean. The filesets already handled nested patterns and petternsets etc. The task writers don't have to handle it. The places where tasks do handle it is for backwards compatability. >> >3. Can a mapper be used in the construction of a FileSet? I'd >> > like to be able to say something like: >> > <fileset id="sources" .../> >> > <fileset id="classes" refid="sources"> >> > <mapper type="glob" from="*.java" to="*.class"/> >> > </fileset> >> >> there has been a proposal for this. It may or may not get through - not >> sure at this moment. > >Want to add mapper support to all existing tasks in one go -- and >to all future tasks where they make sense with *zero* further >effort? This'll do it: don't bother adding mapper support to >tasks; instead factor it out so that tasks don't need to worry >about mappers. agreed. But as I said - we will have to wait till the vote to see if it gets through ;) So far no one besides you and me have been positive about such a feature. (And I am not sure I am completely positive about it). The problem comes because it adds complexity to the build file - where one of our main aims is simplicity ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
