ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: commons dev list CVS component
Date Tue, 09 Aug 2005 10:14:17 GMT
Good - you got my meaning :-)

Jan 

>-----Urspr√ľngliche Nachricht-----
>Von: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com] 
>Gesendet: Dienstag, 9. August 2005 12:10
>An: Ant Developers List
>Betreff: RE: commons dev list CVS component
>
>> From: Jan.Materne@rzf.fin-nrw.de [mailto:Jan.Materne@rzf.fin-nrw.de]
>> 
>> 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:kevin.jackson@it.fts-vn.com]
>> >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: dev-unsubscribe@ant.apache.org For
>> >additional commands, e-mail: dev-help@ant.apache.org
>> >
>> >
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>> 
>> 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message