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 Duncan Davidson <du...@x180.net> on 2001/01/09 09:29:47 UTC
Updated design docs
I expanded a bit the docs I've been working on tonight. There's more to do
obviously, but what's there merits review and comment. They do go a bit more
into some of the details -- and sometimes in a way that expects you to have
a pretty good grasp of concepts (did I say that there's more to do. :)
http://www.x180.net/Projects/Build
Also, I'm on the road right now with intermittent net access and so won't be
turning around mail too quickly.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Updated design docs
Posted by Peter Donald <do...@apache.org>.
At 08:50 9/1/01 -0500, James Cook wrote:
>I think this is a nice document, but it can hardly be considered as a
>requirements document.
I don't think it was meant to be ;)
>I realize he has glommed onto the
>workspace concept introduced in AntFarm, but other than that, it looks
more like
>a personal design document.
Naah the Workspace concept is different from AntFarms. JDDs is more a
central controller project that sets properties and delegates to
sub-modules with properties set. AntFarms is more reusable project file for
components. Both have merits - the Modules concept formalizes a current
practice (namely top-level proect file) into architecture. AntFarm provides
the architecture but does not dictate the style.
>How should someone with a totally different approach submit their ideas? For
>example, I think my proposal has merit by being able to handle the concept
of a
>workspace as simply another Task. And an optional Task, at that. Should I
>produce a more detailed design document similar to James'?
If you like ;)
>Should *all* of the proposal submitters do the same?
If you have a itch then scratch it ;)
>Why don't we spend a collective hour defining what a requirements document
is? I
>was waiting to see a req. doc before spending my time on a design document in
>order to make certain I address each requirement fully.
No one has done any yet. The best place to look was a list of requirements
I emailed that were either
* certain
* maybes
* possibilities
HoweverI couldn't tell you the subject of email its thread or the date I
posted so ... ;) If someone were to create a Functional Specificatioon
Document like Jon suggested then it would be great (*hint* *hint* ;])
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: Updated design docs
Posted by Builds-R-Us <kw...@i2.com>.
It shouldn't take an hour to define :^)
A requirements document should state WHAT the system should
do, in an implementation free way.
A design document should state HOW the system is going to
be written so as to meet the requirements stated in the requirements
document. It's much harder to write requirements without slipping
into 'design mode'. Ideally, every requirement in the requirements
document is referenced in the design document (traceability).
However, as indicated by the subject, James didn't claim to
be providing a requirements doc, but a design doc. Admittedly,
it would be easier to evaluate the design if we had requirements
to judge the design against, and for alternative designs to be
proposed an similarly evaluated.
James Cook wrote:
> I think this is a nice document, but it can hardly be considered as a
> requirements document. There is way too much *how* things will work as opposed
> to *what* needs to be accomplished. I don't want to rabble-rouse (sp?), but
> isn't James simply documenting AntEater? I realize he has glommed onto the
> workspace concept introduced in AntFarm, but other than that, it looks more like
> a personal design document.
>
> How should someone with a totally different approach submit their ideas? For
> example, I think my proposal has merit by being able to handle the concept of a
> workspace as simply another Task. And an optional Task, at that. Should I
> produce a more detailed design document similar to James'? Should *all* of the
> proposal submitters do the same?
>
> Why don't we spend a collective hour defining what a requirements document is? I
> was waiting to see a req. doc before spending my time on a design document in
> order to make certain I address each requirement fully.
>
> jim
>
> ----- Original Message -----
> From: "James Duncan Davidson" <du...@x180.net>
> To: <an...@jakarta.apache.org>
> Sent: Tuesday, January 09, 2001 3:29 AM
> Subject: Updated design docs
>
> > I expanded a bit the docs I've been working on tonight. There's more to do
> > obviously, but what's there merits review and comment. They do go a bit more
> > into some of the details -- and sometimes in a way that expects you to have
> > a pretty good grasp of concepts (did I say that there's more to do. :)
> >
> > http://www.x180.net/Projects/Build
> >
> > Also, I'm on the road right now with intermittent net access and so won't be
> > turning around mail too quickly.
> >
> >
> > --
> > James Duncan Davidson duncan@x180.net
> > !try; do()
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: Updated design docs
Posted by Peter Donald <do...@apache.org>.
At 07:30 14/1/01 -0800, James Duncan Davidson wrote:
>However, also along the way, I've done a lot of thinking about what it means
>to take code open source -- what it means, and why people should do it. If,
>as you and others have said or implied, when somebody open sources code they
>should just walk away from it and never care about it again -- then what's
>the motive?
you did walk away - what was your motive? Then you came back and asked
everyone else who had made ant what it is to walk away. So what would be
the motive of anyone ever working with you again?
If your primary motive is ego feeding then then you will fail. Look through
history and you will see that these people generally induce forks and
eventually end up with people treating as the jokes they are. I get the
impression that a lot of Apache people came from BSD background ?? if so
look at their history and why these projects were initially created. The
original guy wanted authoritative control - he got it and lost the
community. If thats what you want then good luck - you are going to need it.
>Why should anybody do that? How on earth can we talk
>corporations into open sourcing their code if we plan on shutting them
>completely out?
corporations are not motivated by ego - they are in the game to make money.
Buisnesses primarily opensource to reduce costs or to increase income in
some form. There are exceptions - especially with the "opensource
revolution" going on but buisnesses are not motivated by same things people
are.
>It's this attitude or perception that, in major part, has *kept* people that
>can make decisions about making technologies that people want to see open
>sourced from making that decision. Tell me, why should Sun open source Java
>if the open source community is going to flip them the finger?
err - so not bowing down and worshipping suns every motive and actually
thinking for oneself is equivelent to flipping the finger ? Interesting
thought process.
Sun will opensource the product if it is made to appear more lucrative to
do so. They are a company pure and simple.
Would there be forks? undoubtably.
Will they get free research? sure.
Will they get free maintanence? yep.
Will they get new tools to dominate the market? perhaps. I guess this is
major sticking point - currently the JCP is more productive than an
opensource process could be. With a few exceptions opensource thrives in
the case
* good ideas
* bad code
* open participation and extensible
So should java be opensource'd according to the above? Not really - no.
Howevere there are other good reasons for opensourcing under a free license
(MIT/BSD/APL and possibly MPL).
* market penetration
* advertising
* etc
To do this they would have to make sure they established their revenue
stream - which is I guess what there doing with their -
* pay us mega $$ to get verified approach
* pay us mega $$ to use trademark
* sell services etc
and they have to make sure that the majority of community won't fork (which
is almost a reality now).
>Let me put this a different way: Many people, myself included, disagree
>quite a bit with Linus for his views on how threads should be (or shouldn't
>be) in Linux. I don't agree with what he's done there. I've said so -- and
>that's about as far as it goes. If he doesn't agree with me fine. So be it.
>If I care strongly enough, then I guess I should go see if there is a
>different kernel to use that'll do what I want it to do.
right. But if the small core of developers all disagreed with Linus then
how long do you think he would still be head maintainer?
>What do I want? An Ant that is simple, straightforward, and solves a few
>problems along the way. I want that core simple idea that obviously so many
>people liked to be fully solidified. This doesn't mean that other ideas
>aren't valid or good, but an aggregation of ideas isn't necessarily any
>better than just a good implementation of the original idea. What should we
>do then?
Simple - use case. Who uses it, would use it and how. We identify and
prioritize use cases and then design accordingly.
>And why shouldn't I be able to argue for what I want?
argue all you want (withing reason). But gee - you were caught lieing on a
public mailing list whilst attacking another proposal - how the hell do you
expect for people to take you seriously. You still develope your ideas off
apache and for intents and purposes ignore the input of ant-dev. How can
people not be suspicious?
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 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 |
*-----------------------------------------------------*
Ant 2.0 - Frantic: How are properties resolved?
Posted by James Cook <ji...@iname.com>.
> -----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: Updated design docs
Posted by Peter Donald <do...@apache.org>.
At 01:08 14/1/01 -0500, James Cook wrote:
>> Look. I'm not into heavyweight processes. I really don't think that doing
>> design docs and such is really going to get us any closer to having a good
>> piece of code.
>
>I think that others will disagree, I know I do.
me too ;)
If this is the case does anyone object to me developing a FSD like Jon
suggested ?
>It seemed that Peter was championing AntFarm and Connor felt that Ant 1.2
>needed just a little tweaking to shake it up.
I was championing the best bits of any project ;) In reality I probably am
biased towards my own proposal but so far AntFarm has been the best
presented best idea.
>I think that the negative email you receive on this subject is not aimed at
>your ideas, but rather the autocratic manner in which you presume to deliver
>them.
both. I think many of his ideas sucked thou most of the irksome ones have
been modified ;)
>I haven't read *any* discussion about what Ant will become, seriously. Is
>there another forum? Perhaps there should be.
thats because everyones waiting for results of the meeting tomorrow ;)
>Proposal: Create a sepearate mail list "ant-design" to discuss the future of
>Ant 2.0.
naah. I know there is developers on ant-dev who would probably not
participate if we moved list so it would be better to keep it on one list
where they are more likely to contribute ;)
Thou I have been thinking it may be nice to have a contrib list where extra
tasks are discussed and critiqued thou that may be just overhead ;)
>For those that have, they haven't commented on it in a positive or negative
>manner.
Well my main concern with your proposal that blocks me from supporting it
is how you handle
<echo message="Interpret ${this} at runtime" />
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.
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: Updated design docs
Posted by Conor MacNeill <co...@cognet.com.au>.
----- Original Message -----
From: "James Cook" <ji...@iname.com>
>
> It seemed that Peter was championing AntFarm and Connor felt that Ant 1.2
> needed just a little tweaking to shake it up.
>
Let me make my position clear here, as I think you have missed the mark a
little. I envisaged that there would be major changes to Ant between Ant
1.2 and Ant 2.0. These included, just as an example, the need to drop tasks
into Ant by just dropping a task jar into a directory. I did not advocate
"tweaking" so much as natural evolution of the code base. I stated my
concern that a revolution may split the community. You know, I think I
might be right, there :-)
Anyway, that is all I have to say on this thread. You can all resume
flaming each other now :-(
Conor
RE: Updated design docs
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: James Duncan Davidson [mailto:duncan@x180.net]
> Look. I'm not into heavyweight processes. I really don't think that doing
> design docs and such is really going to get us any closer to having a good
> piece of code.
I think that others will disagree, I know I do.
> It comes from your paragraph. If you can't see it, well. Maybe
> highlighting two things here would help:
>
> 1) you said, to quote, "rabble-rouse" (which is spelled correctly
> according to my spell checker).
Interesting quote in your Jakarta membership, "James (is) a rabble rouser
that helped convince Sun that it was a "Good Thing(tm)" to support the
Jakarta Project with code and engineers.".
> 2) there was a smiley face attached. Humor 101.
One man's humor is another man's waste of time. All I see is you trying to
paint me as someone who wants to see you gone. I have no wish for you to go
away, and contrary to your words in my mouth, I have never stated so. I *do*
wish that you would in your position as Chairman of the PMC help to lay a
path to Ant 2.0 that is inclusive and not divisive. I also don't feel that
this requires a heavyweight process. How about we try a simple process that
all can agree with.
At one time, this "simple" process was a call for proposals. That turned
into a fiasco, but I look back at the mail and wonder what would of happened
if you didn't "come back". (Not to be construed as I want you to go away.) I
wonder how the Sam, Peter, Stefan and Connor (and other voices of Ant) would
have handled the process of debate and articulation of a concrete direction?
It seemed that Peter was championing AntFarm and Connor felt that Ant 1.2
needed just a little tweaking to shake it up.
I think that the negative email you receive on this subject is not aimed at
your ideas, but rather the autocratic manner in which you presume to deliver
them.
> <technical debate snipped>
I think I will take your technical critique into a different thread so as
not to turn this thread into a novel.
> Whatever. There's been more productive conversation about what Ant will
> become in the last few weeks and a whole lot less fighting --
> that is until you come in with this post.
I haven't read *any* discussion about what Ant will become, seriously. Is
there another forum? Perhaps there should be.
Proposal: Create a sepearate mail list "ant-design" to discuss the future of
Ant 2.0.
> However, also along the way, I've done a lot of thinking about
> what it means
> to take code open source -- what it means, and why people should
> do it.
> If, as you and others have said or implied, when somebody open
> sources code they should just walk away from it and never care
> about it again -- then what's the motive?
I think you just misquoted everyone who commented about this topic. I don't
remember anyone saying that you should walk away. I believe that you said
that was a choice that *you* made. What everyone objected to was you coming
back and assuming autocratic control.
> What drives anybody who's created something? What drives you to
> keep popping
> up and saying "Hey, nobody is paying attention to this thing I created!"?
I do have a lot of pride in what I do, and *many* people have written
private emails to me supporting my design. The only reason I continue to
push it is the people who decide where Ant is going, all have their pet
projects and have told me that they haven't even looked at the proposal yet.
For those that have, they haven't commented on it in a positive or negative
manner.
> Have I thought many times about how certain things would get simpler if
> everything were indeed a task as you propose. Yep. I have. However, I just
> don't see it keeping things simpler to use.
I *really* don't understand this. What would get more complicated?
jim
Re: Updated design docs
Posted by James Duncan Davidson <du...@x180.net>.
On 1/13/01 8:33 AM, "James Cook" <ji...@iname.com> wrote:
>> I don't think that we need to make such distinctions. If we agree in text
>> how things should work, then we're good.
>
> -1
Look. I'm not into heavyweight processes. I really don't think that doing
design docs and such is really going to get us any closer to having a good
piece of code.
>>> I don't want to rabble-rouse (sp?), but isn't James simply documenting
>>> AntEater? I realize he has glommed onto the workspace concept introduced in
>>> AntFarm, but other than that, it looks more like a personal design document.
>>
>> Am I being asked to go away thank you very much again? :)
>
> I'm not sure where this comment comes from... :|
It comes from your paragraph. If you can't see it, well. Maybe highlighting
two things here would help:
1) you said, to quote, "rabble-rouse" (which is spelled correctly
according to my spell checker).
2) there was a smiley face attached. Humor 101.
> Look, I don't have a problem taking my ideas somewhere else, but I don't
> think we have had a glimmer of proper debate on the technical merits of the
> other proposals. The only stones that you cast my way were your "feelings"
> that a design that generalizes the concepts of a Task the way I do is a
> "bad" thing. That is ridiculous. Give me some criticism that is based in
> something other than your "feelings".
I said that I think/feel that extreme generalization induces complications
that aren't warranted. I don't agree that a Project is itself a Task. I
don't agree that a Property is a Task.
My argument is that we already have a pretty good top level generalization
in the Java Programming Language. It's called java.lang.Object. Sure, some
more specific generalizations are very good to make, but if everything
should be as general as possible, then we should just treat everything as
Objects.
Now, do you want to program using reflection *all* the time? Or do you find
it useful to have a bit of typing -- and then to treat different things
based on their types?
To follow through on that --
a Project/Workspace/Module is a collection of properties, filesets,
and targets
a Target is a collection of Tasks
by treating them separately, we clarify which each means.
So, you say that it makes the code simpler if everything is a Task. That
might be, but then it makes things harder to conceptualize. Maybe things are
too flexible. Why should I have to mentally keep track of whether something
is a Target or a Task? Why can't I just ask it's type? Or use it according
to its type.
As to what constitutes a proper debate... I've commented before, I'll
comment again. Should we institute Robert's Rules of Order here?
>> How many layers of process are we going to put in so that we can have
>> everyone propose something? This isn't a popularity contest. At least it
>> shouldn't be.
>
> I disagree completely. It is a popularity contest, and it should be.
Then we agree to disagree.
> I find the current "process" to be nothing of the sort. OK James,should we
> just sit on our thumbs until you produce the document that will determine
> what Ant 2.0 becomes? This is the most political B.S. I have ever been
> exposed to in an opensource setting. I guess I am naive to assume that this
> sort of thing only happened in corporations.
Whatever. There's been more productive conversation about what Ant will
become in the last few weeks and a whole lot less fighting -- that is until
you come in with this post.
Yes, I did get my feelings hurt. I think Larry Wall would get pissed if
people told him: "Nice thing, that Perl -- but you know what, you don't get
to say anything more about what its going to be." I'm not proud about
feeling that way, but it is the way I felt. And along the way I have said
some things that were stupid and in retrospect are clearly from anger or
whatever. (Yes, anytime you have a group of people, politics are involved).
However, also along the way, I've done a lot of thinking about what it means
to take code open source -- what it means, and why people should do it. If,
as you and others have said or implied, when somebody open sources code they
should just walk away from it and never care about it again -- then what's
the motive? Why should anybody do that? How on earth can we talk
corporations into open sourcing their code if we plan on shutting them
completely out?
It's this attitude or perception that, in major part, has *kept* people that
can make decisions about making technologies that people want to see open
sourced from making that decision. Tell me, why should Sun open source Java
if the open source community is going to flip them the finger? Answer that
one for me and I'll either understand where it is that I went wrong in life
or I'll have the magic answer and will owe you a major debt.
Let me put this a different way: Many people, myself included, disagree
quite a bit with Linus for his views on how threads should be (or shouldn't
be) in Linux. I don't agree with what he's done there. I've said so -- and
that's about as far as it goes. If he doesn't agree with me fine. So be it.
If I care strongly enough, then I guess I should go see if there is a
different kernel to use that'll do what I want it to do.
> What drives your self-serving tendencies? Is it ego? Is it that the other
> ideas truly suck? Is it a future business deal pending on your vision? Is it
> a desire for control? We want to know.
<sarcasm>
Oh yeah -- I'm about to launch ant.com where I'll charge lots of money to
have anybody even talk about Ant, much less use it. And then, I'm going to
build a full operating system on top of Ant which will make millions and
billions.
</sarcasm>
Any business that I have with Ant is crystal clear and has been fully
disclosed. There is nothing else in the shadows.
What drives anybody who's created something? What drives you to keep popping
up and saying "Hey, nobody is paying attention to this thing I created!"?
Anytime anybody creates something, there's some amount of ego, pride, and a
few other things mixed in. If you are going to create things, then you need
to understand that other people who create things are going to have the same
feelings as you do. You shouldn't hate them for it. If it causes you to
disagree with them, then ok, fine. Disagree.
What do I want? An Ant that is simple, straightforward, and solves a few
problems along the way. I want that core simple idea that obviously so many
people liked to be fully solidified. This doesn't mean that other ideas
aren't valid or good, but an aggregation of ideas isn't necessarily any
better than just a good implementation of the original idea. What should we
do then? And why shouldn't I be able to argue for what I want?
Have I thought many times about how certain things would get simpler if
everything were indeed a task as you propose. Yep. I have. However, I just
don't see it keeping things simpler to use.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: Updated design docs
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> On 1/9/01 5:50 AM, "James Cook" <ji...@iname.com> wrote:
> > I think this is a nice document, but it can hardly be considered as a
> > requirements document. There is way too much *how* things will
> work as opposed
> > to *what* needs to be accomplished.
>
> From: James Duncan Davidson [mailto:duncan@x180.net]
> I don't think that we need to make such distinctions. If we agree in text
> how things should work, then we're good.
-1
> > I don't want to rabble-rouse (sp?), but isn't James simply documenting
> > AntEater? I realize he has glommed onto the workspace concept
> introduced in
> > AntFarm, but other than that, it looks more like a personal
> design document.
>
> Am I being asked to go away thank you very much again? :)
I'm not sure where this comment comes from... :|
> > How should someone with a totally different approach submit
> their ideas? For
> > example, I think my proposal has merit by being able to handle
> the concept of
> > a workspace as simply another Task. And an optional Task, at
> that. Should I
> > produce a more detailed design document similar to James'?
> Should *all* of the
> > proposal submitters do the same?
>
> If you have a totally different vision of how Ant should be, comment here.
> If that vision isn't taking off, then maybe its not a) well understood
> enough (which I doubt), or b) maybe it's not what Ant wants to be.
So you are saying that a conceptual approach that you have not written is
"not what Ant wants to be". I received support from some people when I
posted my proposal. Please be aware that Ant does not exist as an entity
capable of deciding what *it* wants to be. That is the job of the
meritocracy (to quote Peter I believe).
> I understand itch scratching. I support it. However, if what you
> want to do
> is not what Ant is trying to be, then you have to consider other
> mechanisms
> of scratching that itch.
Look, I don't have a problem taking my ideas somewhere else, but I don't
think we have had a glimmer of proper debate on the technical merits of the
other proposals. The only stones that you cast my way were your "feelings"
that a design that generalizes the concepts of a Task the way I do is a
"bad" thing. That is ridiculous. Give me some criticism that is based in
something other than your "feelings".
I have a working prototype that functions. It shows how simple the code can
become when one realizes that a Project and a Target are simply Tasks
themselves. It also has a node naming framework so that nodes can be called
multiple times. It has a property system that offers scoped variable
capabilities. It is very script-friendly. It works very well as a build
system, but there is nothing in Frantic that prevents the system from being
used for other purposes. If you want to argue the technical merits of these
items "bring it on".
> > Why don't we spend a collective hour defining what a
> requirements document is?
> > I was waiting to see a req. doc before spending my time on a
> design document
> > in order to make certain I address each requirement fully.
>
> How many layers of process are we going to put in so that we can have
> everyone propose something? This isn't a popularity contest. At least it
> shouldn't be.
I disagree completely. It is a popularity contest, and it should be. The set
of ideas that is most comfortable with the most people should win. Isn't
that what this is all about? We haven't even begun to analyze the strengths
and weaknesses of each proposal.
It seems that most people who have a vote that counts (and some of us that
don't) have submitted proposals. It also seems that these people find it
difficult to put their egos aside to actually evaluate the other proposals,
and post their criticisms in a way that each proposer can respond to.
I find the current "process" to be nothing of the sort. OK James,should we
just sit on our thumbs until you produce the document that will determine
what Ant 2.0 becomes? This is the most political B.S. I have ever been
exposed to in an opensource setting. I guess I am naive to assume that this
sort of thing only happened in corporations.
What drives your self-serving tendencies? Is it ego? Is it that the other
ideas truly suck? Is it a future business deal pending on your vision? Is it
a desire for control? We want to know.
jim
Re: Updated design docs
Posted by James Duncan Davidson <du...@x180.net>.
On 1/9/01 5:50 AM, "James Cook" <ji...@iname.com> wrote:
> I think this is a nice document, but it can hardly be considered as a
> requirements document. There is way too much *how* things will work as opposed
> to *what* needs to be accomplished.
I don't think that we need to make such distinctions. If we agree in text
how things should work, then we're good.
> I don't want to rabble-rouse (sp?), but isn't James simply documenting
> AntEater? I realize he has glommed onto the workspace concept introduced in
> AntFarm, but other than that, it looks more like a personal design document.
Am I being asked to go away thank you very much again? :)
> How should someone with a totally different approach submit their ideas? For
> example, I think my proposal has merit by being able to handle the concept of
> a workspace as simply another Task. And an optional Task, at that. Should I
> produce a more detailed design document similar to James'? Should *all* of the
> proposal submitters do the same?
If you have a totally different vision of how Ant should be, comment here.
If that vision isn't taking off, then maybe its not a) well understood
enough (which I doubt), or b) maybe it's not what Ant wants to be.
I understand itch scratching. I support it. However, if what you want to do
is not what Ant is trying to be, then you have to consider other mechanisms
of scratching that itch.
> Why don't we spend a collective hour defining what a requirements document is?
> I was waiting to see a req. doc before spending my time on a design document
> in order to make certain I address each requirement fully.
How many layers of process are we going to put in so that we can have
everyone propose something? This isn't a popularity contest. At least it
shouldn't be.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Updated design docs
Posted by James Cook <ji...@iname.com>.
I think this is a nice document, but it can hardly be considered as a
requirements document. There is way too much *how* things will work as opposed
to *what* needs to be accomplished. I don't want to rabble-rouse (sp?), but
isn't James simply documenting AntEater? I realize he has glommed onto the
workspace concept introduced in AntFarm, but other than that, it looks more like
a personal design document.
How should someone with a totally different approach submit their ideas? For
example, I think my proposal has merit by being able to handle the concept of a
workspace as simply another Task. And an optional Task, at that. Should I
produce a more detailed design document similar to James'? Should *all* of the
proposal submitters do the same?
Why don't we spend a collective hour defining what a requirements document is? I
was waiting to see a req. doc before spending my time on a design document in
order to make certain I address each requirement fully.
jim
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.net>
To: <an...@jakarta.apache.org>
Sent: Tuesday, January 09, 2001 3:29 AM
Subject: Updated design docs
> I expanded a bit the docs I've been working on tonight. There's more to do
> obviously, but what's there merits review and comment. They do go a bit more
> into some of the details -- and sometimes in a way that expects you to have
> a pretty good grasp of concepts (did I say that there's more to do. :)
>
> http://www.x180.net/Projects/Build
>
> Also, I'm on the road right now with intermittent net access and so won't be
> turning around mail too quickly.
>
>
> --
> James Duncan Davidson duncan@x180.net
> !try; do()
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: Updated design docs
Posted by James Duncan Davidson <du...@x180.net>.
On 1/9/01 12:37 AM, "Peter Donald" <do...@apache.org> wrote:
>> http://www.x180.net/Projects/Build
>>
>> Also, I'm on the road right now with intermittent net access and so won't be
>> turning around mail too quickly.
>
> could you upload it to CVS.
Its on my list... Like I said, I'm working remote right now and so am a
little slow (I'm actually only on the net for a few minutes at a time).
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Updated design docs
Posted by Peter Donald <do...@apache.org>.
At 12:29 9/1/01 -0800, James Duncan Davidson wrote:
>I expanded a bit the docs I've been working on tonight. There's more to do
>obviously, but what's there merits review and comment. They do go a bit more
>into some of the details -- and sometimes in a way that expects you to have
>a pretty good grasp of concepts (did I say that there's more to do. :)
>
>http://www.x180.net/Projects/Build
>
>Also, I'm on the road right now with intermittent net access and so won't be
>turning around mail too quickly.
could you upload it to CVS.
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 |
*-----------------------------------------------------*