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 03:59:48 GMT
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
>
>
> > 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>
>

I was thinking of defining the lib first, separately and then saying what
you want to import from it

<antlib location="http://.../fubar.tsk"
        classpath="...">

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

The reason is that the library itself (in its antlib.xml) should define its
id - not the import statement. IOW, the lib and location are tautological
and potentially conflicting. If we think of the Java analogy, the <antlib>
statements, either implicitly or explicitly provided define the "classpath"
of library ids and the imports use that. Just as in Java you import
"java.io.File", you don't say where File.class exists.


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

In mutant, I support both <include> and the <projectref>. Sometimes you do
want to include a fragment  of a build file. That fragment would be in well
formed XML in a <fragment> element.


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

I was just going to allow property statements in the referencing project to
override the referenced project

<property name="cat.port" value="8080"/>

I've swapped to a dot notation here just to see how it looks - a little
better than # I guess and I agree we don't want to overload the namespace
stuff. I'm not sure of a good separator though.

This all leads into property scoping and immutability, which I know is a
favourite topic. I have been considering a precedence model where properties
can only be overridden by a higher precedence (command line, referencining
project, antcalling project, ...). Probably worth some dicussion. Funny how
these things are all leading into each other.

>
> 	<copy dir="${cat:buildFiles} .... />
>
> where ${buildfiles} is a property defined in "catalina.xml".
>

Yep, that is what I had in mind.


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

Not that keen on the require. I see the projects as still relatively
standalone - not as some form of method.

Conor


Mime
View raw message