Return-Path: 
 <ant-dev-return-14110-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 60501 invoked by uid 500); 25 May 2001 06:00:23 -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 60491 invoked from network); 25 May 2001 06:00:22 -0000
From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: [DISC] details of task library concept
Date: Fri, 25 May 2001 07:02:39 +0100
Message-ID: <008d01c0e4e0$4e44e8c0$697b883e@viquity.com>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <NDBBIMHCHMPELMBMMFIMGECGFKAA.conor@cortexebusiness.com.au>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> >
> >
>
> 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.
>

Well that makes sense but it seems more writing for writing sake.
In Java, classpaths are outside of the language, they are a feature of the
JVM. But in ANT we are having both on the same file, and at the same time, I
see no reason on keeping them separatly just because...

Is there anything that we are gaining by keeping them separate?

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

I really think <includes> will be the cause of problems (and more presure
for mutable variables) if you see MAKE, originally it was all inmutable
variables. Variables took their value before any target is executed. But
with includes and the patterns MAKE developed, they had to add more and more
mutability, and then a way to stop recursive evaliation, and more and more.

My hope is with something like <projectref> we will be able to avoid that.
That is part of the reason I think we should be able to pass parameters to
them.

>
> >
> > 	<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 think indiscriminate overriding is bad, for the same reasons that some of
us complain about <ant*> inheritance rules being broken. If you look at
build files, there are very few variables that are really relevant, the rest
are constructed by composition rules based on the values of that core set. I
would contest that in principle you do not want outside projects modifying
properties outside this core set.

Now, with the existance of a hierarchical naming structure, these issues may
be less so, but still, I would like to see a buils file and be able to
understand which variables may affect other build files and which one do
not.

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

"." is very much use in current builds, I do not think it would be really
such a good idea.

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

I think that the rules need to allow for deferenciating between internal and
public properties. Internal variables should always take their values from
the project defining them. Public or parameters, take their values from
their caller, and any local definition is considered a "default" value in
case no value is passed. Without that we finish with a sort of gigantic
globat name space very difficult to control in large projects.

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

If the project can compute all its inputs, then it has no need for
<require>, but I suspect <projectref>s will be used as a sort of "template"
containing common targets, in that case, it seem reasonable to be able to
declare what are the things that must be provided.

Jose Alberto