ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 09:09:08 GMT
At 04:20 PM 5/23/01 +1000, Conor MacNeill wrote:
>> What we have not defined at this point is whether we should use
>> 1) Entries in the MANIFEST.MF
>> 2) an XML file
>> 3) something else
>> to provide Ant with all necessary information about the specific
>> library.
>I believe it should be an XML file.

agreed - but to minimize the speed hit from scanning multiple jars we
should write a custom SAX listener and not use the same generic mechanism
as ant build files.

>I actually went for ANT-INF/antlib.xml. I can never remember the rationale
>for wars adopting WEB-INF, but I just extended the concept to have a
>separate Ant-specific configuration area.

the recomended way now seems to be META-INF/services/org.apache.ant* for
ant specific meta information. Not sure if we should use it though I would
probably lean towards yes at this stage (unless we end up having oodles of
config settings).

>Whilst we can use <taskdef> in the XML, I don't think it will be exactly the
>same as the taskdef that is supported in the build file. At the very least
>it shouldn't need a classpath.


>As an aside, in mutant I have decided not to differentiate between tasks and
>types. A datatype is a type of task. I found the distinction between types
>and tasks somewhat arbitrary especially since <property> was a task. 

Same but we need to differentiate if we are to have typed registrys. ie
mappers, datatypes and tasks should all be in different categories in

>> * Will each task library be loaded with a class loader of its own to
>> avoid class-name or class-version clashes?
>I believe so.

me too except we need to allow the possibility for cross .tsk dependencies
- something like manifest attribute Ant-Class-Path:

>> * Will each task library be assigned to an XML-Namespace to avoid
>> task-name clashes?
>> IMHO, yes.  Maybe we should use the name of the jar file (without
>> extension) as the namespace prefix.
>I'm reluctant to adopt this. It will make the build files ugly. I don't
>think we should underrate that.
>Another potential issue is that we are starting to overload the namespace
>concept. We were talking about having it for aspect identification. I
>believe it may also be appropriate for resolution of names to projects where
>we support <import> type constructs. We need to be careful these don't
>So, overall, I'm not sure how to handle the name clash.

agreed partially. Using namespaces for aspect attributes and tasks is
compatible though. The real problem is how we deal with namespace cross
project variables/targets because that will definetly clash with our other
uses of namespace ;/

>> We shouldn't store formated docs but only the source XML files for the
>> documentation inside the libs IMHO - I'd put them in META-INF/doc
>> maybe with subdirectories for tasks and types so that a task
>> generating the documentation can easily sort them into categories.
>I expect a separate tool will extract these into a manual so no real impact
>on Ant's core.




| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message