ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Antlib... when?
Date Sat, 04 Jan 2003 16:06:51 GMT
Conor MacNeill wrote:

>> Instead of loading "default" properties from a file in the ant.jar, we
>> can do it for all jars in ${ant.home}/lib. This would make it simple to
>> move the declarations out of the ant.jar and add "default" tasks to the
>> run.
>> Could this be a simple option to use?
> The problem I see with this approach relates to management of task names.
> By removing the management of task names from the properties file in
> ant.jar you open up the system to issues such as task name collisions.
> IOW, since the naming of tasks is no longer under centralized control (ie.
> as defined in Ant's CVS), something needs to be done to manage a
> distributed task namespace.

But we have namespace support now ! :-) 
And naming collision was allwasy a possiblity with taskdef.

> Further I believe build files should make explicit the libraries/tasks
> they depend on. IMHO, we don't want to tie a build file's operation to the

That's a very good poing, I agree. That's why I think using the ns is a good

> So, for me two requirements for antlib
> 1. Global management of task names, handling name collisions, name
> resolution, aliasing, etc.

I'm not sure I understand what you mean - or if NS would cover your

> 2. Declaration of library/task dependencies in build file.


I would add:

3. Easy to develop simple task library ( i.e. a simple properties should
work - even if we support more fancy XML descriptors )>

4. Like in other areas of ant - the system should be flexible and allow 
future enhancements.


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

View raw message