You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2002/05/10 12:05:40 UTC
Bug 5662
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Peter Donald <pe...@apache.org>.
On Fri, 10 May 2002 20:05, Stefan Bodewig wrote:
> (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.
Really ugly but will work with our current system and is "backwards
compatible". So works for me.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat Manager
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Bob Lee" <cr...@crazybob.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Monday, May 20, 2002 9:20 AM
Subject: Re: Tomcat Manager
> Sorry about that, overlooked "get". It seemed obvious, but I would have
> submit an implementation had there not already been one.
>
> Thanks,
> Bob
tomcat4.1 adds some new tasks to do this, mapping down to get underneath
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat Manager
Posted by Bob Lee <cr...@crazybob.org>.
Sorry about that, overlooked "get". It seemed obvious, but I would have
submit an implementation had there not already been one.
Thanks,
Bob
----- Original Message -----
From: "Ian Atkin" <ia...@blueyonder.co.uk>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Monday, May 20, 2002 10:25 AM
Subject: Re: Tomcat Manager
> yep, the <get> task
>
> tomcat's app manager is all http get requests, right? :-)
>
> shouldn't this have gone on ant-user? :-)
>
> Bob Lee wrote:
>
> >Is there already a task to invoke Tomcat Manager application commands?
For
> >example, reload an application.
> >
> >Thanks,
> >Bob
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat Manager
Posted by Ian Atkin <ia...@blueyonder.co.uk>.
yep, the <get> task
tomcat's app manager is all http get requests, right? :-)
shouldn't this have gone on ant-user? :-)
Bob Lee wrote:
>Is there already a task to invoke Tomcat Manager application commands? For
>example, reload an application.
>
>Thanks,
>Bob
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tomcat Manager
Posted by Bob Lee <bo...@crazybob.org>.
Is there already a task to invoke Tomcat Manager application commands? For
example, reload an application.
Thanks,
Bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 13 May 2002, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
>> (A) Always pass user-properties down as normal properties, that way
>> inheritall doesn't make any difference and nested elements can
>> override user properties.
> 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.
I was thinking about magic properties here.
<ant>
<property name="build.sysclasspath" value="ignore" />
</ant>
would cause more than just a few problems in a well-known context.
>> (C) Invent yet another type of property.
>
> I'd have to say that this just "smells" in the Martin Fowler sense.
It sure does, but I think it just points out that our property system
as we are using it today is at least a bit broken. Probably
overloaded by too many concerns that have been pulling on it in
different directions.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> (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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Stefan Bodewig" <bo...@apache.org>
> On Sat, 11 May 2002, Jose Alberto Fernandez <j_...@yahoo.com>
> wrote:
> > I really never undesrtood completely why <param> should not take
> > precedence over -Ds;
>
> So you can say "use jikes" and don't need to care whether ant task
> will properly pass it down to subbuilds or not.
>
I think this is a false argument. Lets follow it through:
1) If I do not mention "build.compiler" as a <param> (which I guess is the case in 99% of builds)
the value of the -D will be passed along just as it is today. So everything is as today.
2) If I go to the trouble to pass a specific value for "build.compiler" as a <param> then most
probably there is a quite good reason why I am passing an specific value (like: this class only
compiles on the classic compiler).
I would say this argument applies in general. The point is, it seems to me in this cases the build
writer should be the one in control.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 11 May 2002, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> <param name='prop' value='xyz' override='true'>
That would be my first two alternatives at once together with giving
the user a chance to chose one of them.
Given the way it works right now and how it works since 1.4.1 we even
have the choice of the default value for the override attribute - as
the behavior currently depends upon the inheritall attribute (which is
a bug).
> I really never undesrtood completely why <param> should not take
> precedence over -Ds;
So you can say "use jikes" and don't need to care whether ant task
will properly pass it down to subbuilds or not.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug 5662
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
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>
<ant target='t3' antfile='subproject.xml'>
<param name='debug' value='false'/>
</ant>
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" <bo...@apache.org>
> 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) Ant.java: line 268. Where we should be using Project.setNewProperty() anyway
because we are adding properties to a new empty project.
2) Available.java: 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) P4Counter.java: 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() instead.
b) P4Change.java: 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>