ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Bug 5662
Date Sat, 11 May 2002 15:36:09 GMT
A possible additional option or alternative capability would be to be
able to tell <ant*> to override its parameters no matter what.
In many circumstances when one specifies -Dprop=value it is to be
used in the project being called, but it may make little or no sense 
three subproject levels below. It would be nice if one could say:

    <param name='prop' value='xyz' override='true'>

which will force the value to be set on the subproject even if set using -D
in the current project. This could fix Stephan example below (although I believe
that some of the alternatives mentioned may be necessary to clean up how the
whole parameter passing mechanism works).

I really never undesrtood completely why <param> should not take precedence
over -Ds; -Ds I see it as the means to change default values:

    <property name='debug' value='false'/>

    <ant target='t1' antfile='subproject.xml'/>

    <ant target='t2' antfile='subproject.xml'>
        <param name='debug' value='${debug}'/>

    <ant target='t3' antfile='subproject.xml'>
        <param name='debug' value='false'/>

The first and second calls will pass the value set by -Ddebug=true naturally,
but if I purposely call with debug=false on the third call, it makes no sense
what so ever to me that a -D should override that. For all matters "debug"
may be used as something else in the subproject and that is why I passed
a specific value insted of propagating my own.

The only reason I see for this behavior is backward compatibility (or backward bugfeature
;-) )
hence my suggestion of having the "override" attribute.

See additional comments below.

Jose Alberto

From: "Stefan Bodewig" <>

> I'm not sure I'm grasping all the things that are related to
> properties, user-properties and the nested elements of <ant*> so I
> thought I'd brain-storm here and gather feedback.
> We have two requirements here - if there are more, then it's good that
> I ask here 8-):
> (1) We want to always propagate properties that have been specified on
> the command line down to subbuilds - and we want them to ultimately
> take precedence.  This is the reason why we have subprojects inherit
> all user-properties.
> (2) We want to have the nested elements of <ant*> take precedence over
> definitions in the called subprojects.  We solve this now by making
> them user-properties in the called subproject.
> This all works well as long as we are dealing with two levels of
> projects, but it starts to get counterintuitive when we add a third
> level:
> <project default="test">
>   <target name="test">
>     <antcall target="test2" inheritAll="false">
>       <param name="p" value="aaa"/> 
>     </antcall> 
>   </target>
>   <target name="test2">
>     <antcall target="test3" inheritAll="false">
>       <param name="p" value="bbb"/> 
>     </antcall> 
>   </target>
>   <target name="test3">
>     <echo>p=${p}</echo>
>   </target>
> </project>
> will give us
> test3:
>      [echo] p=aaa
> instead of bbb because p has become a user property in the second
> project and therefore gets inherited by the third project before the
> nested param tag gets evaluated.
> To make things even more confusing, user-properties of the calling
> project will become "normal" properties of the called project if you
> set inheritall to true.
> So I thought about some ways to solve the problem - and none of them
> seems to really work.
> (A) Always pass user-properties down as normal properties, that way
> inheritall doesn't make any difference and nested elements can override
> user properties.  This allows <ant*> to override command line
> settings, so it violates requirement (1) above.
> For the remaining options I'll assume that user-properties will always
> be passed down as user-properties to make inheritall regular.
> (B) Don't make properties defined by nested elements user-properties,
> treat them as normal properties.  Inherit properties after evaluating
> the nested elements so that nested elements still take precedence over
> normal properties in inheritall="true".
> The problem with this approach is, that tasks in the called project
> that use Project#setProperty to set a property can now override nested
> elements which has been impossible before.  So this violates
> requirement (2).
I took a look at the code. The only usages of Project.setProperty() (which I think 
should be deprecated itself out of the API) are (not counting testcases):

    1) line 268. Where we should be using Project.setNewProperty() anyway
        because we are adding properties to a new empty project.

    2) line 256. Where it is used in deprecated code that barks at you.
        I see very little reason to be influenced in  our solution by this code which was
deprecated a long time ago.

    3) In the perforce tasks, where I think committers need to take a look and fix that code

        because it is violating the rules we are trying to enforce in ANT.
        a) line 128. This task is allowing properties to mutate. It violates
the rules
            and I think it should be fix. There is no reason why it should not use setNewProperty()
        b) line 97. There seem to be some hack at play here with this task
using a property
            named "p4.change" like some sort of internal mutable variable. Not kosher at all.

            I think this is a misuse of the API but in any case it should not affect whatever
we do in <ant*>.

with the above in mind, I see very little reason for needing inventing something new.

> (C) Invent yet another type of property.  One type would be
> user-property and this would strictly be limited to properties set
> before parsing any build file (from the command line for example).
> These would be inherited throughout and couldn't be overridden at all.
> The third level would be properties as we have them now - inherited it
> inheritall is true, the first definition wins.
> The new second level would be in-between and would be used for the
> nested elements.  No special handling in the inheritall case (they'd
> be treated as normal properties) for <ant*> task that spawn yet
> another project and they cannot be overridden in the called project
> (and they cannot override user-properties).
> I'm just afraid that this would make things even more confusing.

I agree with you on making things more confusing. And I think what we should probably do
is (B) and modify setProperty() to write an ugly deprecation message every time someone
uses it. Indicating to use setNewProperty() instead.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message