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 | *-----------------------------------------------------*
