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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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="[EMAIL PROTECTED]"/> > <parameter name="name" value="[EMAIL PROTECTED]"/> > > <!-- 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 | > *-----------------------------------------------------* >
