Jose Alberto Fernandez wrote: > 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.
It should be quite easy to update it - you no longer need most of the hacks, just a simple ComponentHelper. My primary concern with this particular proposal - the XML descriptor. I'm fine with it as long as a simple antlib is also supported, using .properties. There is also the issue of automatic loading of antlibs versus explicit declaration. At least Conor and me ( convinced by Conor ) expressed a preference to explicit. Costin > > 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]>
