ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
Date Wed, 28 Sep 2005 13:10:18 GMT
I would prefer the <fileset>-extension of <taskdef> as DD suggested.
Combined with <import> could ensure, that all antlibs are in.

    <fileset dir="${ant.home}/auto-antlibs" includes="**/*.jar" /> 

Do the WAS buildfiles use <import>s? Then this would be only a modification of one file.


>-----Urspr√ľngliche Nachricht-----
>Von: Steve Loughran [] 
>Gesendet: Montag, 12. September 2005 12:01
>An: Ant Developers List
>Betreff: Re: Antlib autoloading (was Re: cvs commit: 
>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 
>>; 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, 
>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:
>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)
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message