Before we go back and forth until kingdom comes with this , why don't we take a look at the already exiting proposals (already implemented) and forgeting the details of the particular implementations, take a look at the features they offer and decide whether they are good/bad, or whether they cover or not what we expect of <antlib>.
Several of the issues exposed here like what to do about redefining tasks and so on where addressed on the proposal in the /antlib/ which I wrote. I know the architecture is now qute diferent so it is not ablut the code but about the functionality. Jose Alberto > -----Original Message----- > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > Sent: 06 January 2003 23:50 > To: Ant Developers List > Subject: Re: Antlib... when? > > > Costin Manolache wrote: > > > > The surprise would be why would a user (ab)use xmlns in > such a construct :-) > > In the long run, IMOH, we want to have polymorphism - i.e. > passing new > subtypes to a task or implementations of an interface. So, > while today the > namespace doesn't make much sense (since the task defines > what types it will > accept), in the future, it will be necessary. > > <path> > <foo:fileset dir="." /> > </path> > > This would be a reasonable construct (once we agree on the > polymorphism > aspects) to pass a new type of fileset to an existing task. > > So, IMHO, namespaces should be considered at all levels, even > if the first > pass may just be to cause an error. > > Conor > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
