commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)
Date Wed, 30 Oct 2002 20:04:24 GMT
Hi James,

There sure is a lot of overlap between these projects, but  
unfortunately no code overlap.

One way to integrate the projects would be to reuse as much code as  
possible from the other projects. Anteater for example allows Jelly  
scripts to be embedded in Anteater test scripts. There are places  
however where such integration makes less sense, for example for  
features implemented in more than two frameworks. As an example  
Anteater has embedded since its beginning a Tomcat server in it for  
easy testing of servlets, Web apps and asynchronous Web services.

One way we can cooperate I think is to try to come up with a common  
framework, which all could be based on. But the distinction between the  
different tools would then blur dramatically, to the point where only  
one tool is really needed. I'm not sure how we can approach this, as  
each of us has ideas why his/her framework is better than the others ;)  
We can still try to start putting the very common functionality in a  
single framework, and see what happens afterwards. So yes, I agree with  
you we should do this.

-- Ovidiu Predescu <> (Weblog) (Apache, GNU,  
Emacs ...)

On Wednesday, Oct 30, 2002, at 04:17 US/Pacific, James Strachan wrote:

> Sorry to bring up such an old thread. I've just committed a patch  
> supplied
> by Robert Leftwich which allows some easy testing of servlet request  
> using a
> Jelly library which uses an embedded Jetty server.
> org/apa
> che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-type=text/ 
> ewcvs-markup
> It got me thinking; I've always kept an eye on Latka and Anteater and  
> it
> seems like they are getting closer and closer each day. Both use some  
> degree
> of Ant, Jelly, Maven.
> To make unit testing of Jelly easy, JellyUnit got created which has  
> JUnit
> integration, assertions, expression support, XPath validation and  
> schema
> validation (DTD, RelaxNG and XML Schema). Maybe JellyUnit might have  
> some
> use to both Latka and Anteater to help them fit into a JUnit framework  
> (if
> they don't already do that).
> Then folks started adding HTTP client and HTTP server tags to Jelly  
> thats
> starting to blur the lines even more.
> So now we have 3 projects with some overlap. I guess Cactus might  
> overlap
> here too. I get the feeling all these different projects are starting  
> to
> travel in the same direction. I'm just wondering what peoples thoughts  
> were
> on having some possible integration or sharing of code across the  
> various
> projects?
> I'm not exactly sure how or what should happen. Sometimes code should  
> stay
> seperate as it just makes life easier. I just wanted to open a dialog  
> really
> to see if we can think of ways to share or reuse code or somehow work
> together to solve the same goals.
> James
> -------
> ----- Original Message -----
> From: "Jeff Turner" <>
> To: "Jakarta Commons Developers List" <>
> Sent: Thursday, May 16, 2002 5:57 AM
> Subject: Re: Latka & Anteater
>> On Wed, May 15, 2002 at 10:26:47PM -0500, Ivelin Ivanov wrote:
>>> Can some of the Latka experts please comment on how Latka compares to
>>> Anteater (which emerged from Cocoon)?
>> I've worked on both projects, and like both for different reasons.
>> Latka pros:
>>  - Strong typing via a DTD.
>>  - Internally, it's got a very nice delegating-SAX-handler model for
>>    adding new elements.
>>  - Decent XML reporting.
>>  - After all Dion's work, it's docs are rather good.
>> Latka cons:
>>  - A PITA to compile, due to it's many dependencies.  Hopefully that's
>>    changed with Maven.
>>  - The XML file is a bit hard to comprehend at first, due to the use  
>> of
>>    &entities;
>>  - Inflexible XML syntax (see below for definition of 'flexible':)
>> Anteater pros:
>>  - It's based on Ant (it's really a bunch of Ant tasks). This makes it
>>    wonderfully flexible:
>>    - I can parametrize tests, by defining variables like ${host},
>>      ${port}, ${debuglevel} as properties, and reuse them throughout  
>> the
>>      script.
>>    - Through the use of targets, I can group tests together, and with
>>      the 'depends' attribute, can have common groups of tests. Latka's
>>      approach (entities) is workable but not half as nice & intuitive.
>>    - I can <echo> whenever I want, or <fail> halfway through a test.
>>    - I can use Ant's <parallel> to test multiple servers at once.
>>    - I can capture the matched <regexp> or <xpath> value as a  
>> property,
>>      and print it out for debugging.
>>    - I can do conditional logic, eg "If response code is 200, do a
>>      <regexp> test, else if response code is 404, set the ${failed}
>>      variable, else <fail> the test".
>>  - It supports testing of interactive services like SOAP, which need  
>> to
>>    hold a 'conversation' with another HTTP server. It does this by
>>    launching an embedded Tomcat instance, and then registering
>>    'listeners' which validate incoming requests and return specified
>>    responses. Apart from SOAP/web services testing, this allows one to
>>    'unit test' a website: have an Ant script launch the webapp, test  
>> it
>>    and shut it down again.
>>    Here's how you'd launch a Tomcat, and then send a query to
>>    it. Both the request and response are validated with <match> tags:
>>     <servletContainer port="8101"/>
>>     <http description="Test the regexp matcher">
>>       <parallel>
>>         <listener path="/good.html">
>>           <match>
>>             <method value="GET"/>
>>             <sendResponse href="test/responses/good.html" />
>>           </match>
>>         </listener>
>>         <sequential>
>>           <sleep seconds="1"/>
>>           <httpRequest path="/good.html">
>>             <match>
>>               <regexp mustMatch="false" assign="n">exception</regexp>
>> <!--
> mustn't contain the text 'exception' -->
>>               <regexp assign="m"><![CDATA[.*<html>.*<body.*<p.*You
>> sent
> the proper request.*</p>.*</body>.*</html>]]></regexp>
>>             </match>
>>           </httpRequest>
>>         </sequential>
>>       </parallel>
>>     </http>
>> Anteater cons:
>>  - Being based on Ant, Anteater is 'loosely typed', ie scripts aren't
>>    checked against a DTD.
>>  - It's not 1.0-quality yet. Ie, the README file is misleading, and  
>> you
>>    must symlink build/anteater-0.9.x to build/anteater in order to run
>>    the tests. The docs in CVS are rapidly approaching Latka quality,  
>> but
>>    not on the website yet, so it's best to learn by example (see
>>    test.xml).
>>  - I don't think there is any XML reporting mechanism beyond Ant's
>>    standard ability to attach project listeners, which may not provide
>>    sufficient detail (I haven't tested).
>> Btw, there's no reason why Anteater and Latka couldn't share a common
>> API for 'validators'. I'd like to try this, but for now it's less  
>> effort
>> just to duplicate them (there's not that many).
>> HTH,
>> --Jeff

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message