Good - you got my meaning :-) Jan
>-----Ursprüngliche Nachricht----- >Von: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] >Gesendet: Dienstag, 9. August 2005 12:10 >An: Ant Developers List >Betreff: RE: commons dev list CVS component > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> >> ATM tasks and types are declared via >> taskdefs/default.properties and types/default.properties. >> Could we extend that mechanism to allow an AntLib-URI? >> >> taskdefs/default.properties >> ---------------------------------------------------- >> # standard ant tasks >> mkdir=org.apache.tools.ant.taskdefs.Mkdir >> javac=org.apache.tools.ant.taskdefs.Javac >> ... >> # AntLib's >> core=antlib:org.apache.ant.antlib.cvs >> core=antlib:org.apache.ant.antlib.script >> core=antlib:org.apache.ant.antlib.perforce >> ... >> # Standard external >> xmlns:ac=antlib:net.sf.antcontrib >> ... >> > >Well, syntactically it would have to be a little different >as the lefthand side of a properties file needs to be unique :-) >The other thing is for the mechanism to be as lazy as possible >so that you do not end loading every antlib all the time. > >You could thing of something like: > > # AntLib's > antlib:org.apache.ant.antlib.cvs=xmlns > antlib:org.apache.ant.antlib.script=xmlns > antlib:org.apache.ant.antlib.perforce=xmlns > ... > # Standard external > antlib:net.sf.antcontrib=xmlns:ac > >So old CORE antlibs are just specified to be in the default namespace. >This does not addresses lazy loading, but may be a proposal in >the right >direction. > >Jose Alberto > > >> Jan >> >> >> >-----Ursprüngliche Nachricht----- >> >Von: Kev Jackson [mailto:[EMAIL PROTECTED] >> >Gesendet: Dienstag, 9. August 2005 11:27 >> >An: Ant Developers List >> >Betreff: Re: commons dev list CVS component >> > >> > >> >>I would love to remove some of the fat from the current >ANT and move >> >>more things to individual antlibs that people can load on demand. >> >>However, the main issue we need to face is how to maintain easy >> >>backward compatibility at least at the XML level. >> >> >> >>We need to define a proper strategy or antlib definition >> pattern that >> >>allows an installation of ANT to dump a bunch of antlibs >> >somewhere and >> >>the corresponding tasks can be used just as if they where >defined in >> >>CORE (without any need to declare or use additional name-spaces). >> >> >> >>If we solved this issue satisfactorily, we could reorganize >> >the entire >> >>set of CORE and optional tasks allowing for separate releases for >> >>optional components. >> >>And hence allowing for a much more stable CORE and uptodate >> libraries. >> >> >> >>Jose Alberto >> >> >> >> >> >+1 exactly >> > >> > >> >>--------------------------------------------------------------------- >> >To unsubscribe, e-mail: [EMAIL PROTECTED] For >> >additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
