(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.
I think this is the best solution. My reasoning is that is the build file writer wants to make the params passed to a sub-build overridable, that can be achieved by justing using a property value in the subbuild param.
For example, if a build file has
<javac deprecation="true" .../>
the deprecation flag cannot be overridden on the command line.
ON the other hand, if the build file writer choonse to give a control point by
<javac deprecation="${deprecation}" .../>then it can be controlled. I believe the situation with <ant*> is analagous. With
<antcall>
<param name="deprecation" value="true"/>
</antcall>the build file writer has chosen not to give an externally controllable value to the passed parameter, whereas the following does
<antcall>
<param name="deprecation" value="${deprecation}"/>
</antcall>
(C) Invent yet another type of property.
I'd have to say that this just "smells" in the Martin Fowler sense.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
