ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@ebinteractive.com.au>
Subject RE: Some Thoughts on Ant 1.3 and 2.0
Date Thu, 02 Nov 2000 05:47:11 GMT
Read up about the <ant> and <antcall> tasks

http://jakarta.apache.org/ant/jakarta-ant/docs/#ant


--
Conor MacNeill
conor@cortexebusiness.com.au
Cortex eBusiness
http://www.cortexebusiness.com.au

> -----Original Message-----
> From: John Hempe [mailto:jhempe@north.com]
> Sent: Thursday, 2 November 2000 13:31
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: Some Thoughts on Ant 1.3 and 2.0
>
>
> 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
> >
>


Mime
View raw message