ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 06:20:34 GMT
Stefan,

My input is based to some extent on what I have done with mutant.

>
> We've settled on
>
> * allow tasks to be loaded from jars. tasks should be indicated by
>   either xml file in TSK-INF/taskdefs.xml or manifest file.
>
> and we've also agreed that these jars could also contain data types
> and other pluggable components.
>
> 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.

>
> My preference here is to use an XML file and the syntax one would use
> in a build file as well, i.e. use <taskdef> to define a task,
> <typedef> to define a data type and so on.  This file should reside in
> META-INF and I propose META-INF/antlib.xml.  The main reason is
> consistency.
>

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.

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. The
consequences of this are that I do allow any task to exist under a project
and I do allow targetless build files

>
> Other details to resolve are
>
> * Will each task library be loaded with a class loader of its own to
> avoid class-name or class-version clashes?

I believe so.

>
> I'm not a class loader expert and can only hope that breaking JDK 1.1
> compatibility will make the whole class loader business a bit
> easier. At first glance, they should probably be separate.
>
> * 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
interfere.

So, overall, I'm not sure how to handle the name clash.

>
> * The extension of the library file itself.
>
> ".tsk" has been proposed, but this might put too much focus on tasks.
> How about ".ant"?
>

I believe .tsk should be one of them and .zip and .jar others. In any such
files in the appropriate place will automatically be loaded.

I believe we should use .ant files as the build files themselves in
preference to .xml

> * We've agreed to store documentation within the library itself -
> where?
>
> 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.

> * others?
>
> Stefan
>


Mime
View raw message