I would prefer the <fileset>-extension of <taskdef> as DD suggested.
Combined with <import> could ensure, that all antlibs are in.
common.xml
----------
<taskdef>
<fileset dir="${ant.home}/auto-antlibs" includes="**/*.jar" />
</taskdef>
Do the WAS buildfiles use <import>s? Then this would be only a modification of
one file.
Jan
>-----Ursprüngliche Nachricht-----
>Von: Steve Loughran [mailto:[EMAIL PROTECTED]
>Gesendet: Montag, 12. September 2005 12:01
>An: Ant Developers List
>Betreff: Re: Antlib autoloading (was Re: cvs commit:
>ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
>
>Jeffrey E Care wrote:
>> I don't normally speak up on the developer list, but I thought this
>> discussion could benefit from the experience of a *very
>large* product
>> that uses Ant to build.
>>
>> We use Ant + our own extensions (Mantis) to build WebSphere
>> Application Server (and a good number of the stack products
>as well).
>> The Mantis extensions allow for build modularization both on a
>> fine-grain (called
>> "component") and a coarse-grain (called "functional element") scale;
>> Mantis also has tasks that manage the dependencies between these
>> modular units, for purposes of constructing classpaths, scheduling
>> build order, etc.
>>
>> Given that our build is modular, as you might expect we have many
>> hundreds of individual build.xml files in WAS. With that many files
>> it's difficult to ensure that everyone is declaring typedefs
>> correctly, so prior to our adopting Ant 1.6 we were modifying an Ant
>> 1.5.4 distribution to always include the Mantis tasks in
>> oata.tasks.defaults.properties; it was just easier for our
>users that
>> way. Now that we're on an Ant 1.6.5 base we're using namespaces +
>> antlibs to make the Mantis tasks available, which IMO is better than
>> doing a typedef, but on a large scale it's still difficult
>to ensure that everyone is doing the right thing.
>>
>> So, with all of that in mind, I really do like the suggestion of
>> autoloading type & task definitions from META-INF/antlib.xml; I also
>> understand Dominique's concerns about transparency & staying
>in control.
>> Perhaps this behavior could be controlled with a
>command-line switch,
>> say "-autoload" or something along those lines, such that
>the default
>> behavior would be as it is today (i.e. no autoloading), but by
>> specifying the switch Ant could search its classpath to discover the
>> antlibs. This would also yield a nontrivial performance enhancement,
>> as currently each of our modules is effectively reloading
>our antlib,
>> whereas I would think that autoloading would be done once
>(when Ant is bootstrapped).
>>
>
>This sounds like the largest Ant build project I've heard of,
>excluding
>Gump itself, which is so loosely coupled it doesnt really count. We
>have, what, 30 build files in ours and I am still struggling to deal
>with refactoring it to be more effective. The big problem I
>have in mine
>is that with a single ${root.dir}/common.xml containing most stuff, it
>is inordinately brittle. So I am breaking it into separate build files
>with lots of cross <imports>, mandatory namespace declarations for all
>tasks, presets, etc.
>
>My project rework proposal is here:
>
>http://cvs.sourceforge.net/viewcvs.py/*checkout*/smartfrog/core
>/antbuild/doc/third_generation_build_process.sxw
>
>for anyone who wants to view and comment.
>
>I hadnt thought about autoloading; I am happy with explicit loading of
>stuff into their own namespaces, but want to make it easier
>for projects
>to get access to my definitions (or even importable libraries)
>
>-steve
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
