ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: AntEater
Date Thu, 14 Dec 2000 19:05:25 GMT
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               |
*-----------------------------------------------------*


Mime
View raw message