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: reassigning perperty values?
Date Fri, 27 Oct 2000 20:32:33 GMT
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:bodewig@bost.de]
> Sent: Friday, October 27, 2000 8:16 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: reassigning perperty values?
> 
> 
> >>>>> "GS" == Gottfried Szing <goofy@yasd.dhs.org> 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
> 

Mime
View raw message