ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 00:44:40 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> > >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>
>

I like it!

> 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.
>

I would only add the ability to specify the location of the library, for
those cases in which the library resides outside of the ANT installation.

And of course my mantra of being able to specify a classpath to include in
that of the library :-)

So the full syntax would be:

	<import lib="com.m64.task.fubar" task="foo"
		location="${basedir}/tools/m64.tsk" >
		<classpath .... />
	</import>

That I think would give a quite powerful abstraction.

> 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.
>

It should be just the core. Or more exactly, the library lib="ant.core".

> 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?

Something like this is what I think is the right implementation for what
people have refer as <include>. Macro like <include> I feel is a mistake,
here you have a structured a object being referenced and accessed. I will
just add the ability to specify properties to use during the instantiation
of the project reference:

	<projectref name="cat" location="catalina.xml" >
		<property name="port" value="8080" />
	</projectref>

Now, here all the targets share the same dependency graph, as oppose to
<antcall> which does not. And properties defined inside the <projectref>
should be visible in the main project. Now shall we use the name space for
properties also?

	<copy dir="${cat:buildFiles} .... />

where ${buildfiles} is a property defined in "catalina.xml".

Finally, I would suggest adding to <project>s a way to specify required
properties to be suplied by the caller:

	<project name="..." ...>
		<require name="port" />
		...
	</project>

where <require> will fail if there is no property defined with that name. It
works like a parameter declaration.

Jose Alberto


Mime
View raw message