ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: [DISC] details of task library concept
Date Tue, 22 May 2001 21:11:44 GMT

----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Tuesday, May 22, 2001 01:25
Subject: [DISC] details of task library concept

> We've settled on
> * allow tasks to be loaded from jars. tasks should be indicated by
>   either xml file in TSK-INF/taskdefs.xml or manifest file.
> and we've also agreed that these jars could also contain data types
> and other pluggable components.
> What we have not defined at this point is whether we should use
> 1) Entries in the MANIFEST.MF
> 2) an XML file
> 3) something else
> to provide Ant with all necessary information about the specific
> library.
> My preference here is to use an XML file and the syntax one would use
> in a build file as well, i.e. use <taskdef> to define a task,
> <typedef> to define a data type and so on.  This file should reside in
> META-INF and I propose META-INF/antlib.xml.  The main reason is
> consistency.

This came up in batik-dev-l not so long ago.

>From the archives there
Thomas E Deweese, Thursday, April 26, 2001 05:39:-

"   When the ImageTagRegistry is first requested it calls
'getResources("META-INF/MANIFEST.MF")' on it's ClassLoader this
returns all of the manifest files for all the JARS on the class path.

   It then looks for the 'Batik-RegistryEntry' attribute in the
Manifests "Main Attributes" (I'm not sure if we could create our own
section - or exactly how one does that :).

   This attribute should be a white space separated list of fully
qualified class names that implement the RegistryEntry interface.  It
then tries constructing an instance of each and if that succeeds it
registers them with the ImageTagRegistry.

   I have tested this, and it means support for new formats can be
added simply by putting a new jar file on the class path."

This was refined by moving stuff to a separate directory because, as Thomas
says :-

"putting it in a separate file in the META-INF directly has
some merit.  Currently, it ends up looking at _every_ manifest file
in the class path even though most don't have anything in them.  By
putting it in a separate file the 'hit rate' would go way up (much
less wasted work parsing manifest files).  It would also allow us to
name the file 'org.apache.batik' which should prevent any possible
name collisions."

Then Christophe Jolif came in with a pointer to the official route: "looking
at: Manifest

It looks like there is a "standard" way for listing services class in a
jar file (services directory under META-INF). Is there a strong reason
for not using it?"

So the eventual conclusion for xml-batik was to follow the sun jar
guidelines: have a file META-INF/services/org.apache.batik which contains
the batik details; at load time all the instances on the classpath are
located and registered.

I would suggest copying this with some file like
"META-INF/services/org.apache.ant.taskdefs.xml" and whatever internal
representation makes sense. Perhaps the batik codebase would be a good place
to start cut and paste reuse.


View raw message