Read up about the <ant> and <antcall> tasks http://jakarta.apache.org/ant/jakarta-ant/docs/#ant
-- Conor MacNeill [EMAIL PROTECTED] Cortex eBusiness http://www.cortexebusiness.com.au > -----Original Message----- > From: John Hempe [mailto:[EMAIL PROTECTED] > Sent: Thursday, 2 November 2000 13:31 > To: '[EMAIL PROTECTED]' > 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:[EMAIL PROTECTED] > Sent: Wednesday, November 01, 2000 6:12 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Some Thoughts on Ant 1.3 and 2.0 > > > > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > > 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 > > >
