Return-Path: 
 <ant-dev-return-14106-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 58349 invoked by uid 500); 25 May 2001 03:56:30 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 58340 invoked from network); 25 May 2001 03:56:29 -0000
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-dev@jakarta.apache.org>
Subject: RE: [DISC] details of task library concept
Date: Fri, 25 May 2001 13:59:48 +1000
Message-ID: <NDBBIMHCHMPELMBMMFIMGECGFKAA.conor@cortexebusiness.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <008101c0e4b3$e2569d60$697b883e@viquity.com>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> 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