> 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]
