You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by James Cook <ji...@iname.com> on 2001/01/15 05:03:52 UTC
Ant 2.0 - Frantic: How are properties resolved?
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Well my main concern with your proposal that blocks me from supporting it
> is how you handle
>
> <echo message="Interpret ${this} at runtime" />
I handle it by determining the value of ${this} *at* runtime, when that task
is invoked, and without the use of proxies. Please explain what the
shortcomings of this approach are.
> The easiest way that has been suggested is via the use of proxies. The
> "everything is a task" approach gets exceeding complex and looses all it's
> intrinsic simplicity if proxies are used (see Ant1.x for an example). Thus
> I can't see any benefit unless you can think of a way other than proxies
> that the above can be done.
I have never advocated the use of proxies. I see them as heavy and
unnecessary for the benefits they bring.
jim
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 08:08 15/1/01 -0500, James Cook wrote:
>> -----Original Message-----
>> From: Peter Donald [mailto:donaldp@apache.org]
>> Thats what I thought - I am completely and utterly -1 on this aspect.
>> Mainly as it becomes so hard to maintain and requires heaps of extra
>> programming in 90% of the cases. (It is useful in some instances but....)
>> It should be the containers responsibility rather than components. The
>> reason is that moves all complexity to us and leaves task writers with a
>> cake walk ;)
>
>Please elaborate. As far as putting more complexity on us (Ant design), I
>don't see it. In fact, the code that exists now fully supports complex
>property substitution. What is the issue?
What I am saying is that task writers should not have to do a
getProperty()/getAttribute(). All complexity should be on us the engine
writers. So the engine would detect that there is a setFoo() method and
automagically convert the attribute into setFoos() parameter type and then
call setFoo.
>When the program starts, all I have is an object tree. As Tasks get executed
>and nesting levels ensue, I build a property tree that represents the
>runtime structure of the build process. You need two trees because the
>static view (the XML file) does not equal the runtime view. The runtime view
>can jump all over the place in a manner that is not reflected by the task
>hierarchy.
Right - but why do you need to separate the too. Neither of AntEater or
myrmidon separates them - in effect the "runtime" view is throwaway. You
create the object, configure it, execute it and then throw it away. Any
"context" information is past on in variables.
I think we should probably store the execution stack like yours does but I
don't think there is any necessaity to store anything more - or have I
mistaken something ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Thanks to James and Peter (Was: Ant 2.0 - Frantic)
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
At the risk of offending some, I want to publically thank James Cook
and Peter Donald for setting a great example for how technical dialog
and issue negotiation should be accomplished. It has been a long time
in this group since we have seen two people with different viewpoints
be able to discuss the issues objectively, and be willing to put their
egos aside and conceed points to one another where when objective
analysis deems it appropriate.
For me, reading this recent thread has been a spark of hope in what
has been a very demoralizing time on ant-dev. I had just about
convinced myself that this group was going to implode and fragment
into several useless efforts, making my own work on Antidote pretty
much a waste of time. I now have new hope, assuming that such
productive dialog will continue here.
James and Peter, I hope you keep this up, and that others join in
following your mature and professional handling of the issues. The
*immediate* goal is to create a /consensus/ *feature set* and *design
approach* that those willing to participate in can help implement to
become Ant 2.0. Ant 2.0 needs to be a product that we *all* (not just
one or two people) have ownership in, and are all proud of. I believe
that if the dialog continues along the path that you have set up then
we will be making concrete progress to making Ant 2.0 a reality.
Kudos!
Simeon
--
Mustard Seed Software
mailto:simeon@fitch.net
fax:1.309.424.4982
Re: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
> >2. Property values can be changed and the new property value will be
> available
> >to any tasks that are runtime subordinate to the current task.
>
> +1 - unless overidden
I am assuming that you are referring to the ability to set a property higher
than the current scope?
> >3. If a property value is changed by a Task, and the lifecycle of the said
> Task
> >ends, the property value reverts to its original value.
>
> +1 if this occurs by default however overall I think a task should be able
> place a proeprty in any upper context - most will choose top level context
> or current context but some may push the value up two context levels etc
> (ie Tinderbox system)
+1
> >1. A tree that holds the physical Task structure. This contains Task
> instances
> >and its parent-child relationships are the same as the XML file.
> >
> okay lets ignore 2 as all proposals have to have it in some form.
>
> Could you submit a few more tasks (using reflection to set properties) that
> are relatively simple to descibe how you see 1 as happening.
I will look into. I am currently adding the XML parsing. But reflection is next
on the list.
> I have no problem allowing functionality but I do have a problem doing it
> by default. Enabling the functionality comes at a cost (high coupling,
> heavier interfaces, harder to maintain backwards compatability) but as it
> is not always needed - why should all task writers pay the price? It should
> be pay as you play IMHO - the more functionality you use the more complex
> it becomes rather than starting out complex ;)
I agree, but it would be akin to a modular vs. programming language issue. You
don't have to write other methods; you could have only one. It is just a matter
of style. It doesn't incur the costs that you think (high coupling, heavier
interfaces, harder to maintain backwards compatability). At least not that I
see.
jim
Re: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 09:08 16/1/01 -0500, James Cook wrote:
>I think the requirements would be:
>
>1. Supply a property system that works in a scoped manner.
+1
>2. Property values can be changed and the new property value will be
available
>to any tasks that are runtime subordinate to the current task.
+1 - unless overidden
>3. If a property value is changed by a Task, and the lifecycle of the said
Task
>ends, the property value reverts to its original value.
+1 if this occurs by default however overall I think a task should be able
place a proeprty in any upper context - most will choose top level context
or current context but some may push the value up two context levels etc
(ie Tinderbox system)
>4. Task developers should be able to declare properties that are global.
+1 see above
>I have two trees...
>
>1. A tree that holds the physical Task structure. This contains Task
instances
>and its parent-child relationships are the same as the XML file.
>
>2. A tree that gets built on the fly that functions as a stack and holds
>property values. This is the HierarchicalHashtable.
okay lets ignore 2 as all proposals have to have it in some form.
Could you submit a few more tasks (using reflection to set properties) that
are relatively simple to descibe how you see 1 as happening.
>Ant is being pulled in quite a few directions by ppl who *want* to modify
>runtime characteristics. They are doing this via the <if> tasks and the
<select>
>tasks. Also they want this functionality in the <script> task, so I think
that
>it is a no-brainer. I contend that it is better to incorporate this type of
>flexibility now, at design time, rather than shoehorning it in at a later
time.
>As you guys can atest to! :-)
I have no problem allowing functionality but I do have a problem doing it
by default. Enabling the functionality comes at a cost (high coupling,
heavier interfaces, harder to maintain backwards compatability) but as it
is not always needed - why should all task writers pay the price? It should
be pay as you play IMHO - the more functionality you use the more complex
it becomes rather than starting out complex ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
> At 11:40 15/1/01 -0500, James Cook wrote:
> >I dont agree that having a runtime tree (of variables) adds complexity. It
> >is already there in the code now, and it is extremely simple to understand
> >and maintain. It also has the benefit of maintaining scope because it is not
> >flat.
>
> I am not advocating a flat space - just the appearance of a flat space to a
> task writer (unless they are one of the few who set properties and may need
> to crawl up the tree).
I think the requirements would be:
1. Supply a property system that works in a scoped manner.
2. Property values can be changed and the new property value will be available
to any tasks that are runtime subordinate to the current task.
3. If a property value is changed by a Task, and the lifecycle of the said Task
ends, the property value reverts to its original value.
4. Task developers should be able to declare properties that are global.
> >Keeping it in the engine means that you don't have to pass anything
> >around either. This is patterned after the concepts of an interpreted
> >language or a compiler, so we can feel sure that it works well.
>
> Okay - now I am confused ;) From what I understand you now have three trees.
>
> 1. Proxy tree - contains the data required to build the tasks
> 2. Runtime tree - contains the actual task instances
> 3. Data tree - contains the properties, stack trace, etc
>
> So obviously I have got something wrong. Feel free to correct me ;)
I have two trees...
1. A tree that holds the physical Task structure. This contains Task instances
and its parent-child relationships are the same as the XML file.
2. A tree that gets built on the fly that functions as a stack and holds
property values. This is the HierarchicalHashtable.
> >The execution path of a build script should be open to modification if the
> >user requires it. Why not? If it is not necessary for a particular user,
> >then they don't have to use it. It comes free with the design. I can't
> >imagine why we would want to keep this power out of the hands of the power
> >user if it can be completely transparent to those who don't want to use it.
>
> Just because you can - doesn't mean you should ;) That would be the
> flexability syndrome. Obviously I don't understand your design thou so I
> could be wrong but it seems the only reason you need the runtime tree (as
> defined in 2 above) is so you can do this. If you didn't need this then you
> could do away with tree 2 all together ...
Ant is being pulled in quite a few directions by ppl who *want* to modify
runtime characteristics. They are doing this via the <if> tasks and the <select>
tasks. Also they want this functionality in the <script> task, so I think that
it is a no-brainer. I contend that it is better to incorporate this type of
flexibility now, at design time, rather than shoehorning it in at a later time.
As you guys can atest to! :-)
jim
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 11:40 15/1/01 -0500, James Cook wrote:
>I dont agree that having a runtime tree (of variables) adds complexity. It
>is already there in the code now, and it is extremely simple to understand
>and maintain. It also has the benefit of maintaining scope because it is not
>flat.
I am not advocating a flat space - just the appearance of a flat space to a
task writer (unless they are one of the few who set properties and may need
to crawl up the tree).
>Keeping it in the engine means that you don't have to pass anything
>around either. This is patterned after the concepts of an interpreted
>language or a compiler, so we can feel sure that it works well.
Okay - now I am confused ;) From what I understand you now have three trees.
1. Proxy tree - contains the data required to build the tasks
2. Runtime tree - contains the actual task instances
3. Data tree - contains the properties, stack trace, etc
So obviously I have got something wrong. Feel free to correct me ;)
>> >Also, scripting support would benefit greatly from being able to
>> dynamically
>> >change the execution path,
>>
>> -1
>> Execution path should *never* in my opinion outside of a very few rare
>> occasions (ant-call comes to mind) be able to do this thou YMMV ;)
>
>YMMV?
your mileage may vary ;)
>The execution path of a build script should be open to modification if the
>user requires it. Why not? If it is not necessary for a particular user,
>then they don't have to use it. It comes free with the design. I can't
>imagine why we would want to keep this power out of the hands of the power
>user if it can be completely transparent to those who don't want to use it.
Just because you can - doesn't mean you should ;) That would be the
flexability syndrome. Obviously I don't understand your design thou so I
could be wrong but it seems the only reason you need the runtime tree (as
defined in 2 above) is so you can do this. If you didn't need this then you
could do away with tree 2 all together ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> At 10:48 15/1/01 -0500, James Cook wrote:
> >The runtime tree allows variables to have scope much like a
> compiler engine
> >works when making nested or recursive method calls.
> ...snip...
>
> Right but that is not neccessary. You can simply pass around a "context"
> tree. The context tree would have all the information needed - such as
> properties, environment conditions and probably stack trace. By removing
> the necessity of runtime task tree you vastly simplify the design and you
> revert to something more people can understand. Everyone can
> understand the
> "context" subject because it is basically a hashtable or
> properties object ;)
I dont agree that having a runtime tree (of variables) adds complexity. It
is already there in the code now, and it is extremely simple to understand
and maintain. It also has the benefit of maintaining scope because it is not
flat. Keeping it in the engine means that you don't have to pass anything
around either. This is patterned after the concepts of an interpreted
language or a compiler, so we can feel sure that it works well.
> >Also, scripting support would benefit greatly from being able to
> dynamically
> >change the execution path,
>
> -1
> Execution path should *never* in my opinion outside of a very few rare
> occasions (ant-call comes to mind) be able to do this thou YMMV ;)
YMMV?
The execution path of a build script should be open to modification if the
user requires it. Why not? If it is not necessary for a particular user,
then they don't have to use it. It comes free with the design. I can't
imagine why we would want to keep this power out of the hands of the power
user if it can be completely transparent to those who don't want to use it.
jim
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 10:48 15/1/01 -0500, James Cook wrote:
>The runtime tree allows variables to have scope much like a compiler engine
>works when making nested or recursive method calls.
...snip...
Right but that is not neccessary. You can simply pass around a "context"
tree. The context tree would have all the information needed - such as
properties, environment conditions and probably stack trace. By removing
the necessity of runtime task tree you vastly simplify the design and you
revert to something more people can understand. Everyone can understand the
"context" subject because it is basically a hashtable or properties object ;)
>Properties (variables)
>can be set by a task then a sub task is invoked with the variable equal to
>that value. Next the subtask could change the value and invoke another
>subtask. As the tasks finish, any variable settings they have made are lost
>as they are popped off the stack. (Unless of course, they changed a global
>variable which should be allowed.)
+1
>Also, scripting support would benefit greatly from being able to dynamically
>change the execution path,
-1
Execution path should *never* in my opinion outside of a very few rare
occasions (ant-call comes to mind) be able to do this thou YMMV ;)
>or perhaps invoking the same task several times,
>but with different property values.
+1
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> yep - but now why do you need the runtime tree? ;) Why not just
> use a proxy
> tree. The only advantage I see of the runtime tree is to make everything a
> "task". However you will eventually have to deal with "tasks" like target
> that can not have their proxy data evaluated when they are
> evaluated. Which
> puts you precisely back to the start where each task instance is just a
> convenience 20 line class. At which point the whole advantage of the
> "everything is a class" approach fails I believe. Feel free to convince me
> otherwise thou ;)
The runtime tree allows variables to have scope much like a compiler engine
works when making nested or recursive method calls. Properties (variables)
can be set by a task then a sub task is invoked with the variable equal to
that value. Next the subtask could change the value and invoke another
subtask. As the tasks finish, any variable settings they have made are lost
as they are popped off the stack. (Unless of course, they changed a global
variable which should be allowed.)
Also, scripting support would benefit greatly from being able to dynamically
change the execution path, or perhaps invoking the same task several times,
but with different property values.
jim
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 08:26 15/1/01 -0500, James Cook wrote:
>Peter, I re-read your reply and I was confused as to what you were stating.
>I think I have it straight now. You are claiming that by moving the fetching
>of properties into an engine.getProperty(name) method, this is making it too
>difficult for the Task developers.
>
>I am receptive to this as an issue. I would propose that reflection be used
>before calling Task.execute() to populate the appropriately named setters.
>This should take care of that issue, no?
yep - but now why do you need the runtime tree? ;) Why not just use a proxy
tree. The only advantage I see of the runtime tree is to make everything a
"task". However you will eventually have to deal with "tasks" like target
that can not have their proxy data evaluated when they are evaluated. Which
puts you precisely back to the start where each task instance is just a
convenience 20 line class. At which point the whole advantage of the
"everything is a class" approach fails I believe. Feel free to convince me
otherwise thou ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
Peter, I re-read your reply and I was confused as to what you were stating.
I think I have it straight now. You are claiming that by moving the fetching
of properties into an engine.getProperty(name) method, this is making it too
difficult for the Task developers.
I am receptive to this as an issue. I would propose that reflection be used
before calling Task.execute() to populate the appropriately named setters.
This should take care of that issue, no?
jim
> -----Original Message-----
> From: James Cook [mailto:jimcook@iname.com]
> Sent: Monday, January 15, 2001 8:08 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Ant 2.0 - Frantic: How are properties resolved?
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Thats what I thought - I am completely and utterly -1 on this aspect.
> > Mainly as it becomes so hard to maintain and requires heaps of extra
> > programming in 90% of the cases. (It is useful in some
> instances but....)
> > It should be the containers responsibility rather than components. The
> > reason is that moves all complexity to us and leaves task writers with a
> > cake walk ;)
>
> Please elaborate. As far as putting more complexity on us (Ant design), I
> don't see it. In fact, the code that exists now fully supports complex
> property substitution. What is the issue?
>
> > >The HierarchialHashtables are a means of storing property values
> > in a scoped
> > >manner, but they go ahead and store properties in their ${}
> > form. When the
> > >property is requested by the Task, it is substituted at that time.
> >
> > Yep - so you have two object trees - the real object tree and the proxy
> > object tree ?
>
> When the program starts, all I have is an object tree. As Tasks
> get executed
> and nesting levels ensue, I build a property tree that represents the
> runtime structure of the build process. You need two trees because the
> static view (the XML file) does not equal the runtime view. The
> runtime view
> can jump all over the place in a manner that is not reflected by the task
> hierarchy.
>
> jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
>
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Thats what I thought - I am completely and utterly -1 on this aspect.
> Mainly as it becomes so hard to maintain and requires heaps of extra
> programming in 90% of the cases. (It is useful in some instances but....)
> It should be the containers responsibility rather than components. The
> reason is that moves all complexity to us and leaves task writers with a
> cake walk ;)
Please elaborate. As far as putting more complexity on us (Ant design), I
don't see it. In fact, the code that exists now fully supports complex
property substitution. What is the issue?
> >The HierarchialHashtables are a means of storing property values
> in a scoped
> >manner, but they go ahead and store properties in their ${}
> form. When the
> >property is requested by the Task, it is substituted at that time.
>
> Yep - so you have two object trees - the real object tree and the proxy
> object tree ?
When the program starts, all I have is an object tree. As Tasks get executed
and nesting levels ensue, I build a property tree that represents the
runtime structure of the build process. You need two trees because the
static view (the XML file) does not equal the runtime view. The runtime view
can jump all over the place in a manner that is not reflected by the task
hierarchy.
jim
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 01:10 15/1/01 -0500, James Cook wrote:
>I require a Task to get its property from the engine. The PropertyDump Task
>illustrates this through the use of the engine.getPropertyValue(name)
>method.
Thats what I thought - I am completely and utterly -1 on this aspect.
Mainly as it becomes so hard to maintain and requires heaps of extra
programming in 90% of the cases. (It is useful in some instances but....)
It should be the containers responsibility rather than components. The
reason is that moves all complexity to us and leaves task writers with a
cake walk ;)
>The HierarchialHashtables are a means of storing property values in a scoped
>manner, but they go ahead and store properties in their ${} form. When the
>property is requested by the Task, it is substituted at that time.
Yep - so you have two object trees - the real object tree and the proxy
object tree ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> >I handle it by determining the value of ${this} *at* runtime,
> when that task
> >is invoked, and without the use of proxies. Please explain what the
> >shortcomings of this approach are.
>
> how?
> I can't see how your code does it at all. There is no reflection code in
> the code base and not even any generic method I can see? And besides you
> do use proxies - except you call them HierarchialHashtables.
>
> Run through above example - at what stage is setMessage called and what is
> the steps that occur before it ?
I require a Task to get its property from the engine. The PropertyDump Task
illustrates this through the use of the engine.getPropertyValue(name)
method.
The HierarchialHashtables are a means of storing property values in a scoped
manner, but they go ahead and store properties in their ${} form. When the
property is requested by the Task, it is substituted at that time.
jim
Re: Ant 2.0 - Frantic: How are properties resolved?
Posted by Peter Donald <do...@apache.org>.
At 11:03 14/1/01 -0500, James Cook wrote:
>> -----Original Message-----
>> From: Peter Donald [mailto:donaldp@apache.org]
>> Well my main concern with your proposal that blocks me from supporting it
>> is how you handle
>>
>> <echo message="Interpret ${this} at runtime" />
>
>I handle it by determining the value of ${this} *at* runtime, when that task
>is invoked, and without the use of proxies. Please explain what the
>shortcomings of this approach are.
how?
I can't see how your code does it at all. There is no reflection code in
the code base and not even any generic method I can see? And besides you
do use proxies - except you call them HierarchialHashtables.
Run through above example - at what stage is setMessage called and what is
the steps that occur before it ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*