ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Bug 5662
Date Fri, 10 May 2002 10:05:40 GMT
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).

(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.

Stefan

who would be happy if somebody finds a better option.

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message