ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Why Properties became immutable
Date Wed, 26 Jul 2000 03:31:18 GMT
> From: James Duncan Davidson [mailto:duncan@x180.com]

> > I would agree with you on the need to have some way to 
> encapsulate the
> > scope of namedvalues (properties, variables or whatever other name).
> > In particular, I am not sure with the idea of subprojects 
> not being allowed
> > to define their own local variables. This means that is is 
> not possible
> > to have two originally unrelated projects and then make one 
> call the other
> > because the property names may clash. That seems like wrong.
> 
> That does seem wrong. My posts about scoping properties to 
> project were
> stated in the single project setting, but apply almost 
> equally to the tree'd
> project setting. When a target's task starts another ant build, with a
> subproject, that subproject should be "autonomous" in almost 
> every respect
> (except the ability for the parent to set props in the subproject).
> 

So, does this means that <properties> set in the subproject should
override properties set in the parent project? Is that the current
behaviour?
I thought it wasn't. Please correct me if I was wrong.

What it would make sense is that properties passed in the call to <ant>
task should take precedence to values set in the subproject. Does this
looks clean enough or does it seem like spagetty code to you all?
How about other properties not reset in the subproject, shall they still
have the value of the main project? 

Jose Alberto

Mime
View raw message