ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: NameSpace & antlib was (Re: polymorphism)
Date Wed, 30 Apr 2003 17:28:03 GMT
peter reilly wrote:

> I think that agreement is very close.
> 
> What about this proposal:
> 
> The current types and tasks properties files may be combined
> into a antdef.xml file of the form:
> <antdef>
>     <taskdef name="acme" classname="org.acme.Acme"
>                   onerror="fail/report/ignore"/>
>      ...
>      ...
> </antdef>

What is the "onerror" ? We don't have it in the normal taskdef ( or do we ? )

IMO we should recommend and use <typedef> - with tasks as a particular
case of types. If they extend Task - everything fine, if not 

 <typedef name="acme" classname="org.acme.Acme" adapter="org.apache.tools.ant.TaskAdapter"
/>
or the equivalent
 <taskdef .... />

 
> Definer (in the form of <typedef/> or <taskdef/>) can use
> this either as a file or as a resource.
> <typedef antdef=".../ant-contrib.xml" classpath="${ant-contrib.jar}"/>

That's a point where I feel we still need more work. 

I can accept META-INF/antlib.xml, even if I preffer /my/package/antlib.xml,
with "my.package" used as the name of the antlib ( explicitely or in the 
namespace ).



> or
> <typedef antdefresource="net/sf/antcontrib/antdef.xml" classpath="..."/>
> or
> <typedef antdefresource="net/sf/antcontrib/antdef.xml" />
> (if antcontib-xyz.jar is in ${ant.home}/lib").

Or in some path that is added to <loader> ( which I'll try to document this
weekend - I have few days off, changing jobs ).


> For convienance the antdef.xml may be placed a known place in the
> meta directory of jar by the <antjar/> task.
> The <antlib/> task (extending Definer), knows about this
> known location and can then do.

I think the major question to answer first is if it'll be META-INF
or package ( and impliciltey if libs are discovered automatically 
or loaded explicitely ).

Based on this answer - a lot changes. 

 
> <antlib file="${ant-contrib.jar}"/> or <antlib
> library="${ant-contrib.jar}"/> where library is a convienance for
> ${ant.home}/lib.

> 
> An example-
>   <target name="init">
>     <mkdir dir="classes"/>
>     <copy todir="classes" >
>       <fileset dir="src" excludes="**/*.java"/>
>     </copy>
>     <javac srcdir="src" destdir="classes"/>
>     <antjar antdef="src/antdef.xml" destfile="acme.jar">
>       <fileset dir="classes"/>
>     </antjar>
>   </target>
> 
>   <target name="all" depends="init">
>     <typedef antdef="src/antdef.xml" classpath="classes"
>     prefix="typedef."/> <typedef antdefresource="antdef.xml"
>     classpath="classes"
>                   prefix="resource."/>
>     <antlib file="acme.jar" prefix="antlib."/>
>     <antlib prefix="path.">
>       <path>
>         <fileset dir="." includes="**/*.jar"/>
>       </path>
>     </antlib>
> 
>     <typedef.acme name="typedef.acme"/>
>     <resource.acme name="resource.acme"/>
>     <antlib.acme name="antlib.acme"/>
>     <path.acme name="path.acme"/>
>   </target>
> 
> I have code (which uses a lot of the ideas from the antlib proposal)
> that implements the above. I will try to get it in a form ready
> for upload to-nite.

Good. 
My feeling is that if you wait few more days - we can reach an 
agreement and the code should be committed to the main tree. 
I think we are pretty close (at least to a majority if not unanimity )
on the "polymorphism". 


Costin



> 
> Peter
> 
> 
> 
> 
> On Wednesday 30 April 2003 15:16, Costin Manolache wrote:
>> Jose Alberto Fernandez wrote:
>> >> From: Costin Manolache [mailto:cmanolache@yahoo.com]
>> >>
>> >>
>> >> My concerns with getResources() as oposed to
>> >> getResource( PACKAGE/antlib.xml):
>> >>
>> >> 1. startup time. In order to load one library you need to process all
>> >> of them. It can be resolved with caching the result and
>> >> looking at .jar
>> >> modifications. Most likley we'll have dozens of antlibs - and
>> >> that'll only
>> >> grow in time. The processing of (all) TLDs at startup ( for
>> >> tomcat ) adds a
>> >> very visible overhead on startup, and at least tomcat is a
>> >> long-running
>> >> process.
>> >
>> > I agree. But let me just say that I do not believe that in general
>> > people should just shove evry jar in the world in ANT/lib
>> > (this should be basically the core libraries).
>> >
>> > What I thought was to have a separate directory ANT/antlib (or
>> > something) where people can put libraries which they can load easily on
>> > demand. Something like:
>> >
>> > <antlib library="jboss-ant.jar"/>
>> >
>> > which will just look for ANT/antlib/jboss-ant.jar ant load that using
>> > the classloader methanism whatever it is.
>>
>> That means more filesystem specific  code. You can't use getResource() to
>> get META-INF/antlib.xml from a specific jar - unless you're sure that's
>> the only jar with that res. in the classloader. So you either operate on
>> the jar with Zip, or you have to do ugly tricks with the loaders.
>>
>> Plus - a lot of people have the strange habbit of placing the version
>> number in the jar file name ( jboss-ant-1.2.3.jar ). Every time you
>> upgrade an antlib, all build files that use the jar will need to change (
>> or you'll be forced to use indirection ).
>>
>> If you use namespaces - which seems to be what many people want - you'll
>> either have to use ${} in the namespace ( I think most agree this is
>> indeed a bad use of ns ), or the namespace will change if the versioned
>> jars are used ( bad again ).
>>
>> >> 2. Placing multiple antlibs in a single jar may be trickier.
>> >
>> > I prefer to keep things simple, one antlib == one jar. It is the same
>> > for all other things around ejbjars, wars, etc.
>>
>> "Prefer" is one thing, "require everyone" is another.
>>
>> If we place the descriptor in packages - both preferences are possible.
>>
>> Look - I'm fine with either solution, I just have a feeling that we're
>> making the decision without really considering all implications. I don't
>> like "versioned jars", and I don't like big jars combining too many
>> things.
>>
>> >> 3. It may place too much emphasis on the .jars and filesystem layout.
>> >
>> > I still think that when you are really working on a project, you will
>> > have your own directories in the basedir containing the antlibs
>> > required for the project. And your buildfile will just load the antlibs
>> > manually.
>> >
>> > <antlib location="${myantlibs}/special.jar"/>
>>
>> Again - this will have implications in the namespaces.
>>
>> > or we could have something like:
>> >
>> > <antlib>
>> > <fileset dir="${myantlibs}" includes="*.jar"/>
>> > <antlib>
>> >
>> > or something of the sort. Having such a construct working fine for
>> > manual loading would make providing an autoload just trivial.
>> > The main() will just create the fileset for "ANT/lib/*.jar" and just
>> > let the <antlib> do its job.
>> >
>> > My point is to provide the correct level of manual control and then
>> > we can make a decision whether the bootstrapping process of ANT can
>> > just run the task to do any autoloading.
>>
>> A lot of people ( myself included ) seem to like a "repository" that
>> is shared by multiple projects - instead of having all the jars in CVS
>> or managed manually.
>>
>> We must keep in mind this use case - and the fact that the file
>> names may change ( versioning ) and the repository may have more than
>> we need ( startup time, etc ).
>>
>>
>> Costin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org



Mime
View raw message