youys
/
ant

<?xml version="1.0"?>
<document>
  <properties>
    <index value="2"/>
    <author email="antoine@apache.org">Antoine Levy-Lambert</author>
    <title>Antlib Descriptor</title>
  </properties>
  <body>
    <section name="antlib descriptor in the proposal">
      <source><![CDATA[
<antlib version="1.5" >
  <task name="mkdir" class="org.apache.tools.ant.taskdefs.Mkdir"/>
  ...
  <data-type name="fileset" class="org.apache.tools.ant.types.FileSet"/>
  ...
  <role name="filter" class="org.apache.tools.ant.filters.ChainableReader"/>
  ...
  <filter name="escapeunicode" class="org.apache.tools.ant.filters.EscapeUnicode"/>
</antlib>
]]></source>
<p>
This is the layout of the antlib descriptor in the proposal. In each antlib jar file, the descriptor would be found under
META-INF/antlib.xml
</p>
</section>
    <section name="concerns concerning the location of the descriptor (Costin Manolache)">
My concerns with getResources() as opposed to 
getResource( PACKAGE/antlib.xml): 
<ol>
        <li>
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 likely 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.
</li>
        <br/>
        <li>
Placing multiple antlibs in a single jar may be trickier.
</li>
        <br/>
        <li>
It may place too much emphasis on the .jars and filesystem layout.
</li>
        <br/>
        <li>
A bit harder to control ( as we know from c-logging and JAXP ), 
</li>
        <br/>
        <li>Explicit control over what antlibs are to be used - versus loading
everything. Well - I like "magic" loading, but a lot of things in ant
are done explicitely. 
</li>
      </ol>
      <br/>
      <p>
I have no problem accepting a getResources() solution ( just like I'm 
ok with using XML - but not any XML :-), but those issues should be
considered.
<br/>
A lot of the "mess" in ant is the result of doing some things without
considering all implications or just as side effect of how code happened
to work. That's why I'm so strongly for breaking things down to individual
problems instead of a bundle solution. 
</p>

Costin
</section>
  </body>
</document>