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 Fri, 25 May 2001 00:06:32 GMT
> >Not all tasks, but all libraries. In particular, if you think
> that not all
> >installations will have all libraries. Like with the "import"
> statement in
> >Java, explicitly mentioning dependencies is best.
>
> I agree - wanna convince everyone else ? ;)
>
> >> namespaces.
> >
> >How are you going to assign the name spaces? I hope the writer of the
> >buildfile has a say on what names to use.
>
> Haven't been discussed enough but my assumption is something like.
>
> Namepsace+default prefix defined by library writer however
> library user can
> overide prefix (but not namespace).

I have been thinking about this a little and it is interesting. I think for
task name collision avoidance we can perhaps use the Java model with a few
mod cons.

These are my ideas
1. Each library will provide a unique name based on the dns

<antlib id="com.m64.tasks.fubar">
   <taskdef name="foo" .../>
   <taskdef name="bar"   />
</antlib>

2. Projects must declare the tasks they are going to use - similar to a Java
import statement

   <import lib="com.m64.tasks.fubar">

would import all tasks in this library

   <import lib="com.m64.tasks.fubar" task="foo"/>

would import just the foo task definition and

   <import lib="com.m64.tasks.fubar" task="foo" alias="echo"/>

would import foo and make it available as the <echo> task.

3. Certain tasks would be automatically imported in the same way as
Java.lang.* is in Java. This would include most of the current core tasks, I
guess.

4. I don't think any local prefixes should be used as it would make build
files too tied to the local setup - better to stick to global identifiers.

5. certain parts of the identifier namespace would be reserved to ant - i.e.
ant.*

6. XML namespace constructs are not used and are reserved for project
references. (I used to use <import> for this in mutant but maybe
<projectref> would be better, given the above. Something like this

<project name="tomcat">
   <projectref location="jasper.xml" name="jasper"/>
   <projectref location="catalina.xml" name="cat"/>

   <target name="build" depends="jasper:compile, cat:compile"/>
       <javac .../>
       <jasper:jspc .../>
   </target>
</project>

The above example shows the referencing of projects as originally proposed
in AntFarm, without projectpath concept. It also shows the use of the
namespace to construct cross-project dependencies and also the use of a
namespace to use a task definition from another project. This is what I was
getting at when I talked abouyt overloading the namespace concept if we use
it for task collision avoidance.

Thoughts?
Conor


Mime
View raw message