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 2000/12/14 16:22:21 UTC
AntEater
I had deleted some prior email regarding JDD's plans for anteater. Can someone
please repost this message (or refer me to an archive)? Thank you.
Looking at the current source posted for Anteater, I consider myself somewhat
underwhelmed. I really don't see anything truly different between it and the
current version of Ant. Sure the new Task class includes a more JavaBean-centric
implementation (and I believe this is a good thing), but this IMHO can be added
to the existing Ant 1.2.
I guess I am really looking forward to some more code regarding this proposal.
jim
Re: AntEater
Posted by Peter Donald <do...@apache.org>.
At 09:05 17/12/00 -0800, James Duncan Davidson wrote:
>> 1. a stable Project-Target-Task object hierarchy (although these should
really
>> be defined interfaces, not classes).
>
>There's enough functionality that can be implemented in Project, Target, and
>Task to merit them being classes. And, since it's not expected that there
>will be multiple differing implementations of Project, Target, and Task
Theres been requests for it. Quite a few - mainly with respect for adding
extra gee-whiz functionality that should NOT be in core but would be useful
for integration into GUIs/IDEs. Like keeping comments and raising property
change/veto events etc.
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: AntEater
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: James Duncan Davidson [mailto:duncan@x180.net]
> There's enough functionality that can be implemented in Project,
> Target, and
> Task to merit them being classes. And, since it's not expected that there
> will be multiple differing implementations of Project, Target, and Task
> (note that the Task is a façade that hides the AbstractTask implementation
> behind it in AntEater) I don't think that the complexity with making these
> interfaces with backing classes is worth the extra code and obscurity.
I think that just the opposite can make for an interesting design. If
*everything* is simply a Task, the design gets so simple its scary!
jim
Re: AntEater
Posted by James Duncan Davidson <du...@x180.net>.
On 12/14/00 1:09 PM, "James Cook" <ji...@iname.com> wrote:
> I also recognize that most projects like this often do not think beyond their
> intended design. I believe that you custodians of Ant have decided that it is
> time for Ant to break out of its box, and I welcome that. Ant needs to be more
> integration friendly. I would personally like to see:
Actually, I think it's time for Ant to fill its box, not break out of it. :)
> 1. a stable Project-Target-Task object hierarchy (although these should really
> be defined interfaces, not classes).
There's enough functionality that can be implemented in Project, Target, and
Task to merit them being classes. And, since it's not expected that there
will be multiple differing implementations of Project, Target, and Task
(note that the Task is a façade that hides the AbstractTask implementation
behind it in AntEater) I don't think that the complexity with making these
interfaces with backing classes is worth the extra code and obscurity.
> 2. an effective design to support the reading *and* writing of these classes.
Yep... That's what AntEater shoots for.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: AntEater
Posted by James Cook <ji...@iname.com>.
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.net>
> On 12/15/00 8:44 AM, "James Cook" <ji...@iname.com> wrote:
> > I think the concept behind Ant should be changed to be a "Task Execution
> > Engine", and the concept of Project and Target can be generalized into a
> > specific form of a Task.
>
> I disagree. I don't want Ant to be a general tool. I want it to be a Java
> based project build tool. That's it. I realize that the patterns exposed,
> especially the reflection of XML data to objects in a dynamic fashion, is
> pretty flexible in itself and suggests lots of generic ways to do things.
> However, I would rather live through a few iterations of playing with the
> magic inherent before trying to generalize.
I understand that *you* want it to be a project build tool. Others have
expressed desires for it to become an installation framework (very cool if
WebDav tasks are supported). I would find it useful if it was also a test
harness. Who knows what it can become? The basic truth is that whatever it is,
it will execute Tasks.
I would say that a great deal of the code in Ant 1.x comes from the fact that a
Project, Target and Task are three separate objects, when in fact, they are
*all* Tasks. You would be surprised at how much engine complexity is eliminated
by this realization. The elegance of this step doesn't mean that Project and
Target go away. My proposal proves this. It just means that you can also have
(please pardon the pseudo XML):
<install>
<prompt "which config?">
<config>
<os "windows">
<task>
<task>
</os>
</config>
</prompt>
</install>
> I've generalized things too fast, it's fun for the brain, but makes things
> more complicated. Imho.
Please look at the frANTic design document (and checked in code) and then tell
me if you still disagree.
http://www.visualxs.com/products/frantic/index.html (pls pardon the local
hosting...it's also checked in under proposals).
jim
Re: AntEater
Posted by James Duncan Davidson <du...@x180.net>.
On 12/15/00 8:44 AM, "James Cook" <ji...@iname.com> wrote:
> I think the concept behind Ant should be changed to be a "Task Execution
> Engine", and the concept of Project and Target can be generalized into a
> specific form of a Task.
>
> Project would end up being a class that simply implements the Task interface.
>
> In a similar perspective, Install would also be a class that implements Task.
>
> If you want a general tool, then this is a must.
I disagree. I don't want Ant to be a general tool. I want it to be a Java
based project build tool. That's it. I realize that the patterns exposed,
especially the reflection of XML data to objects in a dynamic fashion, is
pretty flexible in itself and suggests lots of generic ways to do things.
However, I would rather live through a few iterations of playing with the
magic inherent before trying to generalize.
I've generalized things too fast, it's fun for the brain, but makes things
more complicated. Imho.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: AntEater
Posted by James Cook <ji...@iname.com>.
I think the concept behind Ant should be changed to be a "Task Execution
Engine", and the concept of Project and Target can be generalized into a
specific form of a Task.
Project would end up being a class that simply implements the Task interface.
In a similar perspective, Install would also be a class that implements Task.
If you want a general tool, then this is a must.
jim
----- Original Message -----
From: "Rosen, Alex" <ar...@silverstream.com>
To: <an...@jakarta.apache.org>
Sent: Friday, December 15, 2000 10:49 AM
Subject: RE: AntEater
> > >While this can be a powerful paradigm, it can also dillute the
> > effectiveness of
> > >Ant's original goal, "Ant is a Java based build tool.".
> >
> > Nope - the users don't care what the backend is - it could be
> > written in
> > perl or c and it wouldn't effect the users besides the few
> > who write tasks.
>
> I agree that there could be confusion, but as long as you use names well, it's
> OK. Saying "Ant 2.0 is a flexible general-purpose blah blah, and by the way it
> can also do builds" will be very confusing. Much better is to say "Myrmidon is
> a flexible general-purpose blah blah. Ant 2.0 is a Java-based build tool,
which
> by the way uses Myrmidon as its back-end."
>
> Alex
RE: AntEater
Posted by "Rosen, Alex" <ar...@silverstream.com>.
> >While this can be a powerful paradigm, it can also dillute the
> effectiveness of
> >Ant's original goal, "Ant is a Java based build tool.".
>
> Nope - the users don't care what the backend is - it could be
> written in
> perl or c and it wouldn't effect the users besides the few
> who write tasks.
I agree that there could be confusion, but as long as you use names well, it's
OK. Saying "Ant 2.0 is a flexible general-purpose blah blah, and by the way it
can also do builds" will be very confusing. Much better is to say "Myrmidon is
a flexible general-purpose blah blah. Ant 2.0 is a Java-based build tool, which
by the way uses Myrmidon as its back-end."
Alex
Re: AntEater
Posted by Peter Donald <do...@apache.org>.
At 04:09 14/12/00 -0500, you wrote:
>Thanks for the lengthy reply. You should really post this mail and some
design
>docs into CVS.
Probably ;)
>If you really want a cure for insomnia, look at the source for
>myrmidon and try to figure out what its purpose/intent is. ;-) Even after
>reading this post, I am not much closer to understanding your proposal.
unfortunately you need to be at least passing familiar with patterns used
in Avalon :/
>I may also be a bit backwards in my thinking, but I think most successful
>projects (opensource or otherwise) have a clearly stated purpose and
direction.
agreed.
>I think the current version of Ant is a very capable, elegant, and easy to
learn
>*build* tool. I would like to see Ant remain a *build* tool. IMHO, task-based
>execution is what Ant is about and what it should remain consistent with.
What the user see will be a clearly defined simple build tool. I actually
intend to write a XSLT sheet across the top of it to simplify it even more.
The reason being that most of the people I have converter to Ant are
web-develoeprs rather than programmers - thus not always comfortabkle with
structure of ant.
>If you can shoehorn different domains into this model then that is great,
but it
>seems like you are advocating the generalization of the current build model.
Why think small when you can think big?
>While this can be a powerful paradigm, it can also dillute the
effectiveness of
>Ant's original goal, "Ant is a Java based build tool.".
Nope - the users don't care what the backend is - it could be written in
perl or c and it wouldn't effect the users besides the few who write tasks.
The taskwriters job will actually be simplified by clearly deliminating
responsibilities. One of the reasons why EJB/Servlet type specs are
successful - they incorporate the same patterns (ie Inversion of Control
and Seperation of Concerns) but do it at a coarser level.
>I also recognize that most projects like this often do not think beyond their
>intended design. I believe that you custodians of Ant have decided that it is
>time for Ant to break out of its box, and I welcome that.
no one else but me and one other has expressed this but I hope there are
others out there who share my vision ;)
>Ant needs to be more
>integration friendly. I would personally like to see:
agreed.
>1. a stable Project-Target-Task object hierarchy (although these should
really
>be defined interfaces, not classes).
done in mymidon and will soon be done in AntEater
>2. an effective design to support the reading *and* writing of these classes.
again - both proposals cover this ;)
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: AntEater
Posted by James Cook <ji...@iname.com>.
Thanks for the lengthy reply. You should really post this mail and some design
docs into CVS. If you really want a cure for insomnia, look at the source for
myrmidon and try to figure out what its purpose/intent is. ;-) Even after
reading this post, I am not much closer to understanding your proposal.
I may also be a bit backwards in my thinking, but I think most successful
projects (opensource or otherwise) have a clearly stated purpose and direction.
I think the current version of Ant is a very capable, elegant, and easy to learn
*build* tool. I would like to see Ant remain a *build* tool. IMHO, task-based
execution is what Ant is about and what it should remain consistent with.
If you can shoehorn different domains into this model then that is great, but it
seems like you are advocating the generalization of the current build model.
While this can be a powerful paradigm, it can also dillute the effectiveness of
Ant's original goal, "Ant is a Java based build tool.".
I also recognize that most projects like this often do not think beyond their
intended design. I believe that you custodians of Ant have decided that it is
time for Ant to break out of its box, and I welcome that. Ant needs to be more
integration friendly. I would personally like to see:
1. a stable Project-Target-Task object hierarchy (although these should really
be defined interfaces, not classes).
2. an effective design to support the reading *and* writing of these classes.
jim
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Thursday, December 14, 2000 2:05 PM
Subject: Re: AntEater
> At 10:22 14/12/00 -0500, James Cook wrote:
> >I had deleted some prior email regarding JDD's plans for anteater. Can
> someone
> >please repost this message (or refer me to an archive)? Thank you.
>
> The archives are available via http://marc.theaimsgroup.com/
>
> >Looking at the current source posted for Anteater, I consider myself somewhat
> >underwhelmed. I really don't see anything truly different between it and the
> >current version of Ant. Sure the new Task class includes a more
> JavaBean-centric
> >implementation (and I believe this is a good thing), but this IMHO can be
> added
> >to the existing Ant 1.2.
> >
> >I guess I am really looking forward to some more code regarding this
> proposal.
>
> You may want to have a look at the mymidon proposal. It is kinda coming at
> the problem from a different angle. Where as Anteater is just rebuilding
> Ant better, mymidon tries to seperate out different concerns so that it is
> trivial to reuse parts of Ant for other purposes.
>
> For example 90% of ant (everything but project + target objects) revolves
> around a task execution engine that gets it's input from an XML-like
> source. What mymidon aimed to do was seperate this out so it could be
> reused. Initially mymidon started out as part of a cron replacement server.
> However it ended up being generic enough in design to be reused in other
> domains.
>
> A number of people have asked for Ant to be reusable in a number of
> different domains (ie as the basis for an installshield type app). There
> are also a number of other domains that I have considered during the design
> such as;
>
> * configure type app
> * parametized test execution engine
> * rebuild something like stylebook
> * Easy GUI integration
>
> So how do these fit the ant model ?
>
> -
> Configure type app is basically something that exectues a number of tasks
> and sets variables based on task execution and at the end writes out the
> variables. This would be very easy to do using Ant tasklet execution engine.
>
> -
> Parametized test execution engine. Last large (> 25,000 lines) project I
> worked on had a lot of testing - about 60% of final code base was test
> cases. Unfortunately they were based on something similar to Junit. This of
> course meant that developers had to be the ones to
> develope/maintain/run/interpret results of test base. This was HELL - would
> have much preferred to get QA peeps to have a look at it. Parametized tests
> would have been ideal. They could have written a test like
>
> <web-compare src="http:127.0.0.1/myresource.xml"
> destination="a/local/file.txt"
> relationship="equal"/>
>
> You could also check for specific response codes for http/whatever. This
> would have saved us much $$ instead of developers handcodeding in values,
> compiling and then running again.
>
> Tests are roughly equivelent to tasks, testsuites are roughly equivelent to
> targets. This way there could be much reuse between the two architectures
> and possible only 4-5 extra classes to develope it !
>
> -
> rebuild something like stylebook.
> If you aware of stylebook it was this very groovy project over at
> xml.apache.org. It never got it's own webpage at all but all the webpages
> over there are made using it and generally it is a really useful tool. The
> one problem was that it rebuilt everything everyrun. Thus if you had a
> large "book" (it's term for a group of documents) you could end up sitting
> twiddling fingers for a bit - only to find at end of build that you
> misspelt argument ;)
>
> Now imagine this integrated with Ant. It usually consist of pages that are
> transformed from XML into project pages. An example of which is
>
> <project>
>
> <parameter name="copyright" value="{@copyright}"/>
> <parameter name="name" value="{@software}"/>
>
> <!-- copy all resources to the targets -->
> <process source="sbk:/style/resources/" producer="directory">
> <processor name="xslt">
> <parameter name="stylesheet"
> value="sbk:/style/stylesheets/directory2project.xsl"/>
> <parameter name="base" value="resources/"/>
> </processor>
> </process>
>
> <xsl:apply-templates/>
>
> </project>
>
> In many ways it is similar to ants model. You have a project, parameters
> (aka properties) and process (aka tasks). Rebuilding this in ant would
> require a bit of work. The process tasks are relatively complex and you
> would have to write a custom builder that sucked in projects from a XSLT
> transform but overall it would possibly result in a better tool. You could
> make each task check whether it actually needs to update it's destination
> based on file time changes etc.
>
> -
> Easy GUI integration
> A lot of people want this and the best/easiest way is give them access to a
> generic object model one step abstracted from actual tasks. Both proposals
> do this.
>
> ......
>
> Considering that all of these things can be done without compromising ants
> design or making it any more complex. Actually it will end up becoming
> buzzword compliant with any OO type conference (OOPSLA comes to mind) as it
> uses all the "approved" designed patterns ;)
>
> The only problem (or blessing depending on perspective) is that it relies
> on another project (Avalon @ java.apache.org/framework).
>
> Anyways enough talking - I think my insomnia is cured now ;)
>
>
> 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: AntEater
Posted by Peter Donald <do...@apache.org>.
At 10:22 14/12/00 -0500, James Cook wrote:
>I had deleted some prior email regarding JDD's plans for anteater. Can
someone
>please repost this message (or refer me to an archive)? Thank you.
The archives are available via http://marc.theaimsgroup.com/
>Looking at the current source posted for Anteater, I consider myself somewhat
>underwhelmed. I really don't see anything truly different between it and the
>current version of Ant. Sure the new Task class includes a more
JavaBean-centric
>implementation (and I believe this is a good thing), but this IMHO can be
added
>to the existing Ant 1.2.
>
>I guess I am really looking forward to some more code regarding this
proposal.
You may want to have a look at the mymidon proposal. It is kinda coming at
the problem from a different angle. Where as Anteater is just rebuilding
Ant better, mymidon tries to seperate out different concerns so that it is
trivial to reuse parts of Ant for other purposes.
For example 90% of ant (everything but project + target objects) revolves
around a task execution engine that gets it's input from an XML-like
source. What mymidon aimed to do was seperate this out so it could be
reused. Initially mymidon started out as part of a cron replacement server.
However it ended up being generic enough in design to be reused in other
domains.
A number of people have asked for Ant to be reusable in a number of
different domains (ie as the basis for an installshield type app). There
are also a number of other domains that I have considered during the design
such as;
* configure type app
* parametized test execution engine
* rebuild something like stylebook
* Easy GUI integration
So how do these fit the ant model ?
-
Configure type app is basically something that exectues a number of tasks
and sets variables based on task execution and at the end writes out the
variables. This would be very easy to do using Ant tasklet execution engine.
-
Parametized test execution engine. Last large (> 25,000 lines) project I
worked on had a lot of testing - about 60% of final code base was test
cases. Unfortunately they were based on something similar to Junit. This of
course meant that developers had to be the ones to
develope/maintain/run/interpret results of test base. This was HELL - would
have much preferred to get QA peeps to have a look at it. Parametized tests
would have been ideal. They could have written a test like
<web-compare src="http:127.0.0.1/myresource.xml"
destination="a/local/file.txt"
relationship="equal"/>
You could also check for specific response codes for http/whatever. This
would have saved us much $$ instead of developers handcodeding in values,
compiling and then running again.
Tests are roughly equivelent to tasks, testsuites are roughly equivelent to
targets. This way there could be much reuse between the two architectures
and possible only 4-5 extra classes to develope it !
-
rebuild something like stylebook.
If you aware of stylebook it was this very groovy project over at
xml.apache.org. It never got it's own webpage at all but all the webpages
over there are made using it and generally it is a really useful tool. The
one problem was that it rebuilt everything everyrun. Thus if you had a
large "book" (it's term for a group of documents) you could end up sitting
twiddling fingers for a bit - only to find at end of build that you
misspelt argument ;)
Now imagine this integrated with Ant. It usually consist of pages that are
transformed from XML into project pages. An example of which is
<project>
<parameter name="copyright" value="{@copyright}"/>
<parameter name="name" value="{@software}"/>
<!-- copy all resources to the targets -->
<process source="sbk:/style/resources/" producer="directory">
<processor name="xslt">
<parameter name="stylesheet"
value="sbk:/style/stylesheets/directory2project.xsl"/>
<parameter name="base" value="resources/"/>
</processor>
</process>
<xsl:apply-templates/>
</project>
In many ways it is similar to ants model. You have a project, parameters
(aka properties) and process (aka tasks). Rebuilding this in ant would
require a bit of work. The process tasks are relatively complex and you
would have to write a custom builder that sucked in projects from a XSLT
transform but overall it would possibly result in a better tool. You could
make each task check whether it actually needs to update it's destination
based on file time changes etc.
-
Easy GUI integration
A lot of people want this and the best/easiest way is give them access to a
generic object model one step abstracted from actual tasks. Both proposals
do this.
......
Considering that all of these things can be done without compromising ants
design or making it any more complex. Actually it will end up becoming
buzzword compliant with any OO type conference (OOPSLA comes to mind) as it
uses all the "approved" designed patterns ;)
The only problem (or blessing depending on perspective) is that it relies
on another project (Avalon @ java.apache.org/framework).
Anyways enough talking - I think my insomnia is cured now ;)
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 |
*-----------------------------------------------------*
Test. Please kids, don't do this at home
Posted by James Duncan Davidson <du...@x180.net>.
On 12/18/00 1:15 AM, "James Duncan Davidson" <du...@x180.net> wrote:
> On 12/18/00 9:24 AM, "THE PRINCE" <rv...@dnm.it> wrote:
>
>> please unsubscribe me!
>
> Done. As well, I'm going to put in the footer that gives unsubscribe info.
> Argh.
Hopefully, this will have unsubscribe info at the bottom.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: UNSUBSCRIBE ME PLEASE
Posted by James Duncan Davidson <du...@x180.net>.
On 12/18/00 9:24 AM, "THE PRINCE" <rv...@dnm.it> wrote:
> please unsubscribe me!
Done. As well, I'm going to put in the footer that gives unsubscribe info.
Argh.
--
James Duncan Davidson duncan@x180.net
!try; do()
UNSUBSCRIBE ME PLEASE
Posted by THE PRINCE <rv...@dnm.it>.
please unsubscribe me!
r-a-v-i
RE: AntEater
Posted by James Cook <ji...@iname.com>.
> -----Original Message-----
> From: James Duncan Davidson [mailto:duncan@x180.net]
> I'm not done yet. Heck, it doesn't even dogfood itself yet.
Sorry, I didn't mean to sound critical. I was just hoping to glean more
about the "email proposal" from the source code.
jim
Re: AntEater
Posted by James Duncan Davidson <du...@x180.net>.
On 12/14/00 7:22 AM, "James Cook" <ji...@iname.com> wrote:
> Looking at the current source posted for Anteater, I consider myself somewhat
> underwhelmed. I really don't see anything truly different between it and the
> current version of Ant. Sure the new Task class includes a more
> JavaBean-centric implementation (and I believe this is a good thing), but this
> IMHO can be added to the existing Ant 1.2.
I'm not done yet. Heck, it doesn't even dogfood itself yet.
However, I'm not totally surprised that you are under whelmed. The goal here
is simplification down to what I intended Ant to be. Gee whiz features will
reveal themselves slowly.
Like the <buildtarget target="main" if="foo"/> as a logic flow construct
implemented as a task showing off the power of having a decent data model
and the ability to tweak it. :)
> I guess I am really looking forward to some more code regarding this proposal.
I've been sick all this last week, and putting together a new home office
while being sick -- so I've been slow. More code coming soon.
--
James Duncan Davidson duncan@x180.net
!try; do()