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
idea.
> 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
requirement.
> 2. Declaration of library/task dependencies in build file.
+1
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.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
