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:[EMAIL PROTECTED]
>> >>
>> >>
>> >> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
