I may be arguing(sp?) for breaking buildfiles left and right, but I really think it is wrong to presume that any ANT file called from another is a related subproject.
To give you an example: Lets assume I have this website project that uses Tomcat, Cocoon, xerces, xalan, and my own stuff. Lets assume (and here is the leap of faith) that I do not trust distributions and I like to compile stuff from sccratch. I should be able to write and ANT build file with a target "all" as follows: <target name="all" depends="xerces,xalan,tomcat,cocoon,mysite" /> <copy .../> </target> Each one of this targets just call <ant> on the respective project build files. Now, I think it is clear that there is no reason whatsoever to assume that properties of the same name on those subprojects have the same meaning and much less should have the same value. Otherwise we would have to reqire that every project in the world use a different "property name space" for their properties. In my view, there are two types of buildfiles: (1) Autonomous build files (for a better name) which set all their properties to the correct values before they are used. (2) Dependant buildfiles, that expect some of their properties (maybe most of them) to be set by a calling buildfile. When an autonomous file calls another, the number of properties that we want to maintain is usually small (my theory) and that we can achieve using <property> or <param>. Most other properties are completely insignificant or their value must be different on the context of the subproject. So, as I mentioned in the past, for me the "correct behaviour" is to allow properties defined in the caller to be overwritten by definitions on the subproject. The exception to this is the -D option or its equivalent <param> (or <property>) nested element on <ant> task. This still lives the issue of testing for properties ( if="prop.name" ). When an unrelated property of the same name is defined in the caller project, we may get the wrong behavior in the subproject. Which means, we probably need a way to say "undefine this property in the subproject" ( <param name="xxx" undefined="true" /> ). Opinions? Maybe I have a very narrow view of how people use subprojects. Are there any other usage patterns that may clash with this case? Maybe there is a work around. Jose Alberto > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Friday, October 27, 2000 8:16 AM > To: [EMAIL PROTECTED] > Subject: Re: reassigning perperty values? > > > >>>>> "GS" == Gottfried Szing <[EMAIL PROTECTED]> writes: > > GS> But there is no way to define an explicit override. > > This is what I said, we probably need a way to say it is OK to > override this. IMHO the master build has to decide which are allowed > to be overriden and not the sub build. > > Your example is very simple to solve BTW: > > GS> <target name="compileit"> > GS> <property name="SOURCES" value="x1.java,x2.java" /> > GS> <antcall target="compile_sources" /> > GS> > GS> <property name="SOURCES" value="x4.java,x3.java" /> > GS> <antcall target="compile_sources" /> > GS> </traget> > > what you want is > > <target name="compileit"> > > <antcall target="compile_sources"> > <param name="SOURCES" value="x1.java,x2.java" /> > </antcall> > > <antcall target="compile_sources"> > <param name="SOURCES" value="x4.java,x3.java" /> > </antcall> > </target> > > which is a lot easier to understand IMHO. > > And then as a short term solution (until we have decided on the future > of properties) you can write your own task, say mutableproperty that > does the same as <property> but doesn't check whether the property > already exists. You can always call Project.setProperty, it's just > <property> that doesn't want to override properties. > > Stefan >
