Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <1F0E90080295D4118E7900D0B77E76B71D2D8A@TENNORTH05>
From: John Hempe <jhempe@north.com>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: Some Thoughts on Ant 1.3 and 2.0
Date: Wed, 1 Nov 2000 18:31:09 -0800 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

What *is* the standard way to invoke a subproject using Ant?  Where should I
go for documentation on how subproject-invocation semantics are supposed to
work, including propagation of properties?

Sorry I'm not at the level of improving Ant, just trying to understand its
more complex uses right now.  

--John


-----Original Message-----
From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
Sent: Wednesday, November 01, 2000 6:12 PM
To: 'ant-dev@jakarta.apache.org'
Subject: RE: Some Thoughts on Ant 1.3 and 2.0


> From: Conor MacNeill [mailto:conor@ebinteractive.com.au]
> 
> Duncan,
> 
> > >
> > > Conor's approach to explicitly list the properties you 
> want to pass
> > > down to a sub project might be even simpler and clearer.
> >
> > Maybe, but the approach as stated would map exactly to how env
> > vars work in
> > Unix with processes/subprocesses. I'd rather map to this 
> than have more
> > machinery in place that tells what variables are passed where.
> >
> 
> I think adopting the env var model is fine, but it really 
> implies to me that
> properties must be mutable in the sub-build just as env vars 
> are in Unix
> subprocesses. Also, I think Unix processes can use procedural logic to
> decide what to do when a environment variable is already set. 
> There are even
> special syntax such as ${parameter:-word} for conditionally setting
> properties. Would we need these in ant?
> 

My original comments allowed for this. In other words, I could live with
inherited values of properties being mutable in subprojects. This is not
the same as allowing changing the value of a property withing a projact
execution.

> If we adopt mutability of properties then we lose the ability for the
> command line or parent build to override the values set up in 
> the subbuild.
> This was the original reason that properties were made immutable IIRC.
> 
Not necessarily, the "-D" or <param>/<property> nested element will
behave as the property being defined in the context of the callee.

The way I see this to be implemented is very much in the spirit of
function invocations:

Properties are set only once in the context of execution of a project.
A context is started by running ANT or executing the <ant> or <antcall>
tasks. 
  - A property has a value if it is defined in some of the callers
execution contexts.
  - A <property> task will associate a value for the property in the
current context, if there is no value associated in the 
current context.
  - The "-D" and nested <param>/<property> elements of <antcall>/<ant>
associate the value in the context of the callee (subproject).

which means the subproject cannot change the value of the property.
But notive that sub-suprojects can change it, since they are not local.

The main problem with this approach is that there is no way to unset
a variable in a subcontext. This to me is the basic problem with
allowing inheritance.

> We also have the issue of managing the property namespace to 
> avoid name
> conflicts. I think this can be a problem with Unix 
> environment variables
> too.
> 

This is true. Any inheritance mechanism will have to dealt with this issue.
This is the only thing making me ambivalent about inheritance.

> In general, I always like things to be explicit. You know 
> that what you read
> in the build file will be what is sent to the subbuild. 
> Implicitly copying
> all properties means I cannot know what gets sent to the 
> subbuild. I guess
> the model I am advocating is the method-call model - no side effects.
> 
> 
> > >>> (2) Do we want mutable properties or not?
> > >
> > > JDD> Yes.
> 
> Just to be clear we are taking mutability at the <property> 
> tag level. There
> has always been property mutability at the script and task level. For
> example this would work as expected.
> 
> <property name="x" value="hello"/>
> <property name="x" value="${x} goodbye"/>
> 

Actually, if we are going to have mutable properties then I would argue
that we are doing scripting. And then we can go into the scripting wars once
again :-(

> >
> > But -- properties should only be scoped at the project level --
> > and defined
> > at the project level.. :)
> >
> 
> I agree but I think it is too late for that. Without mutability people
> wanted to control to what value some properties get set and 
> they did that by
> scoping property tags within targets. Many examples existed, 
> including some
> Tomcat build files IIRC, that led people to believe that 
> properties could be
> scoped in that way. There were many surprises when this did 
> not work. The
> feedback, I think indicated that people really did want 
> properties to be
> scoped. It will be difficult to take that away.
> 

I am one who uses those techniques. In many cases you need to be able to
set properties (e.g., configure directory locations) based on things
like <available>. If all property definitions where at the project
level, there is no way to do any conditional configuration.

Please, do not tell me that I should use some other configuration tool
to generate the values for properties. Unless that tool has the current 
power of ANT, it wont be able to do what is needed. 
But if it has the power of ANT, why would anyone need ANT for?

Jose Alberto


> Conor
>