You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dp...@yahoo.com> on 2002/04/24 16:07:18 UTC

[VOTE] JXPath 1.0 Release Plan

I am calling for a vote on the JXPath 1.0 Beta Release
Plan

The timeline of this release plan is as follows


April 29 [Monday]

We release JXPath 1.0 beta 1.  

>From this time until release, the main focus will be
on documentation and addressing both new and
outstanding bugs. I'd like to increase the number of
unit tests and I'd like also to improve the general
level of javadoc that exists for all JXPath classes.

New betas will be issued weekly, as necessary, to
address issues arising.


May 27 [Monday]

1. Depending on the stability of the Beta, the Release
Manager will call for a vote to adopt the latest beta
build as the 1.0 release. In any case I believe we
should have a stable beta for two weeks before the
release vote will be called, so this date is somewhat
flexible.

I volunteer to be release manager for this release.

Regards
Dmitri Plotnikov.
dmitri@apache.org

Let me start with my vote
1. Adopt Proposed Release Plan    [+1]


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [VOTE] JXPath 1.0 Release Plan

Posted by Jeff Turner <je...@socialchange.net.au>.
+1

--Jeff

On Wed, Apr 24, 2002 at 07:07:18AM -0700, Dmitri Plotnikov wrote:
> I am calling for a vote on the JXPath 1.0 Beta Release
> Plan
> 
.. 
> I volunteer to be release manager for this release.
> 
> Regards
> Dmitri Plotnikov.
> dmitri@apache.org
> 
> Let me start with my vote
> 1. Adopt Proposed Release Plan    [+1]
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Morgan Delagrange <md...@yahoo.com>.
Which HTTP classes do Anteater use?  If it's HTTP
Client, session support shouldn't be too tough to add.

--- Ivelin Ivanov <iv...@apache.org> wrote:
> 
> Session/cookie support is essential indeed.
> I assumed it's supported in Anteater.
> 
> 
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> Sent: Thursday, May 16, 2002 6:21 PM
> Subject: Re: Latka & Anteater
> 
> 
> > On Thu, May 16, 2002 at 10:41:55AM -0500, Morgan
> Delagrange wrote:
> > >
> > > ----- Original Message -----
> > > From: "Ivelin Ivanov" <iv...@apache.org>
> > >
> > > > Jeff,
> > > >
> > > > Thank you for the extensive response.
> > > >
> > > > I am having hard time making a choice, but it
> appears that Anteater
> was
> > > > built from scratch based on your experience
> with Latka and is
> therefore a
> > > > more viable long term solution.
> >
> > Nono.. Ovidiu Predescu wrote Anteater, in order to
> automate Cocoon
> > testing (at least partly). Here is his initial
> post (2001-09-21)
> > outlining the need, and proposed Ant-based
> solution:
> >
> >
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100108643304886&w=2
> >
> > I pointed Ovidiu to Latka, saying:
> >
> >   "Note that [Latka] doesn't use Ant. I suspect
> this is actually a good
> >   thing. Ant 1.x is not flexible enough to be
> easily repurposed as a
> >   http testing engine"
> >   -
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100121712029019&w=2
> >
> > .. and how wrong I was ;P Ovidiu coded up Anteater
> in a remarkably short
> > period of time, and announced an initial version
> here:
> >
> >
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100221277132628&w=2
> >
> > (Full cocoon-dev thread is at
> >
>
http://marc.theaimsgroup.com/?t=100108670400002&r=1&w=2)
> >
> > So the point is, Anteater was done in full
> knowledge of Latka (and
> > Cactus). Ovidiu just wanted to try the Ant
> approach, and proved rather
> > spectactularly that it's a good one. Anteater is a
> shining example of
> > successful opportunism, whereas Latka is a shining
> example of
> > traditional software engineering, crafting a
> solution to a problem.
> >
> > > I don't know about that...  :)  I think the
> differences are greater than
> > > they appear; it depends on what your needs are. 
> I'd try to enumerate
> which
> > > product is better for what, but it's open to
> interpretation and personal
> > > preference.
> >
> > Objectivism is overrated ;) I'm sure anything you
> have to say would be
> > useful for people choosing.
> >
> > > > Can latka be used for writing complete test
> case scenarios: e.g.
> login, go
> > > > through a product purchase, logout?
> > >
> > > I've written tests like that.  You can wrap
> tests in a "session" tag,
> which
> > > retains cookies and referers between requests. 
> You can't tell Latka to
> fill
> > > out forms or push buttons, but you can set
> request parameters and
> request
> > > headers to simulate that kind of user activity.
> >
> > Anteater doesn't have a <session> tag yet (it's in
> the TODO), so can't
> > do this sort of thing.
> 
> 
> >
> > > > Do you plan to include an option for JUnit
> reporting in Anteater
> > > > similar to Latka's, so that tests can
> integrated with all other
> > > > junit tests?
> >
> > Yes that's planned, and there is already a
> <formatter> element
> > implemented, but I've never seen it working.
> Ovidiu might know more.
> >
> >
> > --Jeff
> >
> > > At some point, Latka will probably come with an
> Ant task.
> > >
> > > > Regards,
> > > >
> > > > Ivelin
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 


=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Ivelin Ivanov <iv...@apache.org>.
Session/cookie support is essential indeed.
I assumed it's supported in Anteater.


----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 6:21 PM
Subject: Re: Latka & Anteater


> On Thu, May 16, 2002 at 10:41:55AM -0500, Morgan Delagrange wrote:
> >
> > ----- Original Message -----
> > From: "Ivelin Ivanov" <iv...@apache.org>
> >
> > > Jeff,
> > >
> > > Thank you for the extensive response.
> > >
> > > I am having hard time making a choice, but it appears that Anteater
was
> > > built from scratch based on your experience with Latka and is
therefore a
> > > more viable long term solution.
>
> Nono.. Ovidiu Predescu wrote Anteater, in order to automate Cocoon
> testing (at least partly). Here is his initial post (2001-09-21)
> outlining the need, and proposed Ant-based solution:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100108643304886&w=2
>
> I pointed Ovidiu to Latka, saying:
>
>   "Note that [Latka] doesn't use Ant. I suspect this is actually a good
>   thing. Ant 1.x is not flexible enough to be easily repurposed as a
>   http testing engine"
>   - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100121712029019&w=2
>
> .. and how wrong I was ;P Ovidiu coded up Anteater in a remarkably short
> period of time, and announced an initial version here:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100221277132628&w=2
>
> (Full cocoon-dev thread is at
> http://marc.theaimsgroup.com/?t=100108670400002&r=1&w=2)
>
> So the point is, Anteater was done in full knowledge of Latka (and
> Cactus). Ovidiu just wanted to try the Ant approach, and proved rather
> spectactularly that it's a good one. Anteater is a shining example of
> successful opportunism, whereas Latka is a shining example of
> traditional software engineering, crafting a solution to a problem.
>
> > I don't know about that...  :)  I think the differences are greater than
> > they appear; it depends on what your needs are.  I'd try to enumerate
which
> > product is better for what, but it's open to interpretation and personal
> > preference.
>
> Objectivism is overrated ;) I'm sure anything you have to say would be
> useful for people choosing.
>
> > > Can latka be used for writing complete test case scenarios: e.g.
login, go
> > > through a product purchase, logout?
> >
> > I've written tests like that.  You can wrap tests in a "session" tag,
which
> > retains cookies and referers between requests.  You can't tell Latka to
fill
> > out forms or push buttons, but you can set request parameters and
request
> > headers to simulate that kind of user activity.
>
> Anteater doesn't have a <session> tag yet (it's in the TODO), so can't
> do this sort of thing.


>
> > > Do you plan to include an option for JUnit reporting in Anteater
> > > similar to Latka's, so that tests can integrated with all other
> > > junit tests?
>
> Yes that's planned, and there is already a <formatter> element
> implemented, but I've never seen it working. Ovidiu might know more.
>
>
> --Jeff
>
> > At some point, Latka will probably come with an Ant task.
> >
> > > Regards,
> > >
> > > Ivelin
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Jeff Turner <je...@socialchange.net.au>.
On Thu, May 16, 2002 at 10:41:55AM -0500, Morgan Delagrange wrote:
> 
> ----- Original Message -----
> From: "Ivelin Ivanov" <iv...@apache.org>
> 
> > Jeff,
> >
> > Thank you for the extensive response.
> >
> > I am having hard time making a choice, but it appears that Anteater was
> > built from scratch based on your experience with Latka and is therefore a
> > more viable long term solution.

Nono.. Ovidiu Predescu wrote Anteater, in order to automate Cocoon
testing (at least partly). Here is his initial post (2001-09-21)
outlining the need, and proposed Ant-based solution:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100108643304886&w=2

I pointed Ovidiu to Latka, saying:

  "Note that [Latka] doesn't use Ant. I suspect this is actually a good
  thing. Ant 1.x is not flexible enough to be easily repurposed as a
  http testing engine"
  - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100121712029019&w=2

.. and how wrong I was ;P Ovidiu coded up Anteater in a remarkably short
period of time, and announced an initial version here:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100221277132628&w=2

(Full cocoon-dev thread is at
http://marc.theaimsgroup.com/?t=100108670400002&r=1&w=2)

So the point is, Anteater was done in full knowledge of Latka (and
Cactus). Ovidiu just wanted to try the Ant approach, and proved rather
spectactularly that it's a good one. Anteater is a shining example of
successful opportunism, whereas Latka is a shining example of
traditional software engineering, crafting a solution to a problem.

> I don't know about that...  :)  I think the differences are greater than
> they appear; it depends on what your needs are.  I'd try to enumerate which
> product is better for what, but it's open to interpretation and personal
> preference.

Objectivism is overrated ;) I'm sure anything you have to say would be
useful for people choosing.

> > Can latka be used for writing complete test case scenarios: e.g. login, go
> > through a product purchase, logout?
> 
> I've written tests like that.  You can wrap tests in a "session" tag, which
> retains cookies and referers between requests.  You can't tell Latka to fill
> out forms or push buttons, but you can set request parameters and request
> headers to simulate that kind of user activity.

Anteater doesn't have a <session> tag yet (it's in the TODO), so can't
do this sort of thing.

> > Do you plan to include an option for JUnit reporting in Anteater
> > similar to Latka's, so that tests can integrated with all other
> > junit tests?

Yes that's planned, and there is already a <formatter> element
implemented, but I've never seen it working. Ovidiu might know more.


--Jeff

> At some point, Latka will probably come with an Ant task.
> 
> > Regards,
> >
> > Ivelin

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Ivelin Ivanov" <iv...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 8:29 AM
Subject: Re: Latka & Anteater


> Jeff,
>
> Thank you for the extensive response.
>
> I am having hard time making a choice, but it appears that Anteater was
> built from scratch based on your experience with Latka and is therefore a
> more viable long term solution.

I don't know about that...  :)  I think the differences are greater than
they appear; it depends on what your needs are.  I'd try to enumerate which
product is better for what, but it's open to interpretation and personal
preference.

> Can latka be used for writing complete test case scenarios: e.g. login, go
> through a product purchase, logout?

I've written tests like that.  You can wrap tests in a "session" tag, which
retains cookies and referers between requests.  You can't tell Latka to fill
out forms or push buttons, but you can set request parameters and request
headers to simulate that kind of user activity.

> Do you plan to include an option for JUnit reporting in Anteater similar
to
> Latka's, so that tests can integrated with all other junit tests?

At some point, Latka will probably come with an Ant task.

> Regards,
>
> Ivelin
>
>
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Thursday, May 16, 2002 12: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)?
> > >
> > > http://sourceforge.net/projects/aft/
> >
> > 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Ivelin Ivanov <iv...@apache.org>.
Jeff,

Thank you for the extensive response.

I am having hard time making a choice, but it appears that Anteater was
built from scratch based on your experience with Latka and is therefore a
more viable long term solution.
Can latka be used for writing complete test case scenarios: e.g. login, go
through a product purchase, logout?

Do you plan to include an option for JUnit reporting in Anteater similar to
Latka's, so that tests can integrated with all other junit tests?

Regards,

Ivelin


----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 12: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)?
> >
> > http://sourceforge.net/projects/aft/
>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by James Strachan <ja...@yahoo.co.uk>.
Thanks for the heads up Jeff.

Incidentally I've been approaching the functional testing issue from a
slightly different tack lately; using JSTL tags to perform XPath, XSLT, SQL,
HTTP, JMS, soap calls etc. For example I'm building a bunch of SQL related
unit tests, so that after various processes are run I can validate the
contents of a database. So I can iterate through XML files containing the
expected data and compare it to the database state. I can use the same
mechanism for preloading the database with sample data.

I'm using Jelly as the processing engine; its kinda like a simple XML based
JSP engine using custom tags to do all the work as well as supporting an
expression language for doing things like ${a.b} or
${customer.orders[12].calculateTotal()} - the expression language is
implemented by the Jexl project in the sandbox.

So writing the test scripts is not unlike building JSTL/JSP scripts. It also
means we can reuse a large collection of standard tag definitions (JSTL) as
well as using a standard expression language to make it easy to work with
beans, and XPath for XML.

There's a Jelly Ant task which (like with Anteater) allows you to access all
of Ant's properties using the usual ${foo.bar} style of expressions; though
unlike Anteater non-string objects can be worked with too. For example to
iterate over an SQL result set and output the results as SAX events you can
use the following

<j:jelly xmlns:j="jelly:core" xmlns:sql="jelly:sql">
  <sql:setDataSource url="${databaseUrl}" driver="${databaseDriver}"
user="${databaseUser}"/>

  <sql:query var="results">
    select * from <j:expr value="${databaseTable}"/>
  </sql:query>

  <dataSet>
    <j:forEach items="${results.rowsByIndex}" var="row">
      <row>
      <j:forEach var="columnName" items="${results.columnNames}"
indexVar="i">
        <field column="${columnName}"><j:expr value="${row[i]}"/></field>
      </j:forEach>
      </row>
    </j:forEach>
  </dataSet>
</j:jelly>

A tag is just a bean with a 'run' method; Jelly will set the various
properties from XML attributes then evaluate the tag. So tags are quite like
Tasks in Ant - so Jelly is similar to AntEater - though Jelly is based on
the concept of XML output pipelining; one tag can emit XML events and its
parent's tag can consume/transform them.

Also tags can be defined dynamically using Jelly script; so I could define a
tag to represent a SOAP service call, which can transform the body and
output, then I can pipeline the output into another tag to do XSLT, XPath,
IO etc. So using the Jelly scripts is a neat way to process XML, SOAP & web
services too.

e.g.

<file:write name="output.xml">
   <!-- transform the output of a SOAP call -->
  <xsl:transform xslt="foo.xsl">

    <!-- call a SOAP service --->
    <babelfish:translate from="EN" to="FR">
      <!-- maybe use other tags to produce the body -->
      <!-- e.g. from working with beans, XPath or SQL -->
      Jelly is cool stuff!
    </babelfish:translate>

  </xsl:transform>
<file:write>


I'd like to make Ant tasks available as tags within Jelly, then Jelly and
Anteater could be mixed inside one script.

Its still a bit early days (and documentation is pretty much non existent)
but hopefully given a bit of time Jelly might compare well with Latka and
Anteater.

James
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 6: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)?
> >
> > http://sourceforge.net/projects/aft/
>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Morgan Delagrange <md...@yahoo.com>.
Hi all,

Just a few comments.  OK, maybe a few more than a few.  :)

----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, May 16, 2002 12: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)?
> >
> > http://sourceforge.net/projects/aft/
>
> 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.

On top of that, you can add new custom validators to Latka without
recompiling it.  I don't know if this is a feature of Anteater or not.
That's the real benefit of the delegation model.  Since it assumes that the
validator will perform its own SAX handling and release to the XML processor
when its done, you can customize a validation with any combination of
arbitrary elements (although you'll probably want to retain a validatable
DTD).

I'd like to try to extend this plugability in other areas.  I think it may
be possible to plug in entirely new top level tasks (e.g. plug in XML-based
GUI tests like those in "Abbot" http://sourceforge.net/projects/abbot/).

>  - Decent XML reporting.
>  - After all Dion's work, it's docs are rather good.

I might add:

  - Decent web interface

It's still a pain to build, so I hope to fix that.

I like Latka's constrained syntax.  In my view, it makes writing tests
easier for folks who are less sophisticated technically.  A trained QA
engineer could write simple Latka tests quite easily.  As in all things, it
depends on what your requirements are.

> Latka cons:
>  - A PITA to compile, due to it's many dependencies.  Hopefully that's
>    changed with Maven.

Yup.

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

Actually, you can do that in Latka too (and I highly recommend making at
least the host and port configurable in most cases).  You can configure
variables with any combination of command-line properties and prop files.

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

Yeah, that is one feature that I miss.  The Latka way to do it is to group
distinct tests into separate files and combine them in different XML files.
Some advantages wrt. organizing large test suites, but not as intuitive.

>    - I can <echo> whenever I want, or <fail> halfway through a test.

You can "echo" now in a Latka suite via the <reportMessage/> tag.  It
doesn't work quite the same way as an Ant echo though.   Latka doesn't have
a fail tag, although it probably could.

>    - I can use Ant's <parallel> to test multiple servers at once.

Another nice feature.  I'd like to see Latka do something like that someday.

>    - 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).

Me too.

>
> HTH,
>
> --Jeff
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by di...@multitask.com.au.
Nathan Coast and I had a chat about this one night (my time, day yours) on 
IRC/email for Maven, and we need:

appserver stuff:
- start
- stop
- deploy war, ear, rar etc
- undeploy war, ear, rar etc
- 'save config' if possible

For a bunch of supported appservers: Tomcat, Jetty, JBoss, WebLogic, 
WebSphere, iPlanet etc....

We are also using cactus for our testing (along with StrutsTestCase), and 
it'd cool to have all this available for tests :)

"James Strachan" <ja...@yahoo.co.uk> wrote on 31/10/2002 02:33:34 
AM:

> From: "Vincent Massol" <vm...@octo.com>
> > Cactus can use any JUnit test runner. Thus it should be able to use 
the
> > exsiting JellyUnit tags with no problem. However, before running the
> > tests there needs some preparations to make everything automatic:
> > - packaging the application as a war or ear
> > - configuring the container
> > - starting it
> > - deploying the app in it
> > - stopping it
> >
> > These could be easily achieved through a combination of Ant and Jelly
> > tags, potentially used in a Cactus Tag library which would make the
> > whole thing easier and more coherent to use?
> 
> Sounds good to me.
> 
> The war/ear would be generated by the build process I guess. Different 
tests
> may want to configure the container, start it, deploy app, stop it in
> multiple times. e.g. to test the same war or ear on different deployment
> configurations, containers or platforms. So deploying artifacts should 
be
> part of the test case; whereas the war or ear should be part of the 
build
> process shouldn't it?
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
> --
> To unsubscribe, e-mail: 
<ma...@jakarta.apache.org>
> For additional commands, e-mail: 
<ma...@jakarta.apache.org>
> 

> ForwardSourceID:NT00088916 
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Vincent Massol" <vm...@octo.com>
> Cactus can use any JUnit test runner. Thus it should be able to use the
> exsiting JellyUnit tags with no problem. However, before running the
> tests there needs some preparations to make everything automatic:
> - packaging the application as a war or ear
> - configuring the container
> - starting it
> - deploying the app in it
> - stopping it
>
> These could be easily achieved through a combination of Ant and Jelly
> tags, potentially used in a Cactus Tag library which would make the
> whole thing easier and more coherent to use?

Sounds good to me.

The war/ear would be generated by the build process I guess. Different tests
may want to configure the container, start it, deploy app, stop it in
multiple times. e.g. to test the same war or ear on different deployment
configurations, containers or platforms. So deploying artifacts should be
part of the test case; whereas the war or ear should be part of the build
process shouldn't it?

James
-------
http://radio.weblogs.com/0112098/

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by Vincent Massol <vm...@octo.com>.
Cactus can use any JUnit test runner. Thus it should be able to use the
exsiting JellyUnit tags with no problem. However, before running the
tests there needs some preparations to make everything automatic:
- packaging the application as a war or ear
- configuring the container
- starting it
- deploying the app in it
- stopping it

These could be easily achieved through a combination of Ant and Jelly
tags, potentially used in a Cactus Tag library which would make the
whole thing easier and more coherent to use?

-Vincent

> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: 30 October 2002 12:17
> To: Jakarta Commons Developers List
> Subject: [latka][anteater][jelly] possible integration... (was Re:
Latka &
> Anteater)
> 
> 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.
> 
> http://cvs.apache.org/viewcvs/jakarta-commons-
> sandbox/jelly/src/test/org/apa
> che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-
> type=text/vnd.vi
> 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
> -------
> http://radio.weblogs.com/0112098/
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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)?
> > >
> > > http://sourceforge.net/projects/aft/
> >
> > 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> __________________________________________________
> 
> Do You Yahoo!?
> 
> Everything you'll ever need on one web page
> 
> from News and Sport to Email and Music Charts
> 
> http://uk.my.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by Ovidiu Predescu <ov...@apache.org>.
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.

Regards,
-- Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (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.
>
> http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jelly/src/test/ 
> org/apa
> che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-type=text/ 
> vnd.vi
> 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
> -------
> http://radio.weblogs.com/0112098/
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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)?
>>>
>>> http://sourceforge.net/projects/aft/
>>
>> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by Janek Bogucki <ya...@studylink.com>.
Latka does allow parameterization of tests via preprocessing of the test
suite document. It goes like this

>From test-suite.xml

<suite defaultHost="${DEFAULT_HOST}"
        defaultPort="80"
        label="foo">

then on the command line

    $ latka.sh <test-suite-url> prop:DEFAULT_HOST=foo.example.com

While this topic is up could someone commit my documentation patch for
latka? It's still useful to the current alpha release even though it appears
that Morgan is removing XML parsing support from latka, and replacing it
with Jelly.

http://issues.apache.org/bugzilla/show_bug.cgi?id=13426

-Janek


> From: "James Strachan" <ja...@yahoo.co.uk>
> Reply-To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Date: Wed, 30 Oct 2002 12:17:19 -0000
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Subject: [latka][anteater][jelly] possible integration... (was 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)?
>>> 
>>> http://sourceforge.net/projects/aft/
>> 
>> 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.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by Morgan Delagrange <md...@yahoo.com>.
I don't have any objection to Latka/Anteater
integration.  It's actually something I've been
meaning to re-open, since using Jelly makes Latka both
more JUnit and Ant-friendly.

--- James Strachan <ja...@yahoo.co.uk> 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.
> 
>
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jelly/src/test/org/apa
>
che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-type=text/vnd.vi
> 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
> -------
> http://radio.weblogs.com/0112098/
> ----- Original Message -----
> From: "Jeff Turner" <je...@socialchange.net.au>
> To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> 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)?
> > >
> > > http://sourceforge.net/projects/aft/
> >
> > 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 


=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


[latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)

Posted by James Strachan <ja...@yahoo.co.uk>.
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.

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jelly/src/test/org/apa
che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-type=text/vnd.vi
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
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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)?
> >
> > http://sourceforge.net/projects/aft/
>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Latka & Anteater

Posted by Jeff Turner <je...@socialchange.net.au>.
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)?
> 
> http://sourceforge.net/projects/aft/

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Latka & Anteater

Posted by Ivelin Ivanov <iv...@apache.org>.
Can some of the Latka experts please comment on how Latka compares to
Anteater (which emerged from Cocoon)?

http://sourceforge.net/projects/aft/




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [VOTE] JXPath 1.0 Release Plan

Posted by Juozas Baliuka <ba...@centras.lt>.
+1
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<dm...@apache.org>
Sent: Thursday, April 25, 2002 7:25 AM
Subject: Re: [VOTE] JXPath 1.0 Release Plan


> +1
>
> On Wed, 24 Apr 2002, Dmitri Plotnikov wrote:
>
> > Date: Wed, 24 Apr 2002 07:07:18 -0700 (PDT)
> > From: Dmitri Plotnikov <dp...@yahoo.com>
> > Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>,
> >      dmitri@apache.org
> > To: commons-dev@jakarta.apache.org
> > Subject: [VOTE] JXPath 1.0 Release Plan
> >
> > I am calling for a vote on the JXPath 1.0 Beta Release
> > Plan
> >
> > The timeline of this release plan is as follows
> >
> >
> > April 29 [Monday]
> >
> > We release JXPath 1.0 beta 1.
> >
> > >From this time until release, the main focus will be
> > on documentation and addressing both new and
> > outstanding bugs. I'd like to increase the number of
> > unit tests and I'd like also to improve the general
> > level of javadoc that exists for all JXPath classes.
> >
> > New betas will be issued weekly, as necessary, to
> > address issues arising.
> >
> >
> > May 27 [Monday]
> >
> > 1. Depending on the stability of the Beta, the Release
> > Manager will call for a vote to adopt the latest beta
> > build as the 1.0 release. In any case I believe we
> > should have a stable beta for two weeks before the
> > release vote will be called, so this date is somewhat
> > flexible.
> >
> > I volunteer to be release manager for this release.
> >
> > Regards
> > Dmitri Plotnikov.
> > dmitri@apache.org
> >
> > Let me start with my vote
> > 1. Adopt Proposed Release Plan    [+1]
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Games - play chess, backgammon, pool and more
> > http://games.yahoo.com/
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [VOTE] JXPath 1.0 Release Plan

Posted by "Craig R. McClanahan" <cr...@apache.org>.
+1

On Wed, 24 Apr 2002, Dmitri Plotnikov wrote:

> Date: Wed, 24 Apr 2002 07:07:18 -0700 (PDT)
> From: Dmitri Plotnikov <dp...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
>      dmitri@apache.org
> To: commons-dev@jakarta.apache.org
> Subject: [VOTE] JXPath 1.0 Release Plan
>
> I am calling for a vote on the JXPath 1.0 Beta Release
> Plan
>
> The timeline of this release plan is as follows
>
>
> April 29 [Monday]
>
> We release JXPath 1.0 beta 1.
>
> >From this time until release, the main focus will be
> on documentation and addressing both new and
> outstanding bugs. I'd like to increase the number of
> unit tests and I'd like also to improve the general
> level of javadoc that exists for all JXPath classes.
>
> New betas will be issued weekly, as necessary, to
> address issues arising.
>
>
> May 27 [Monday]
>
> 1. Depending on the stability of the Beta, the Release
> Manager will call for a vote to adopt the latest beta
> build as the 1.0 release. In any case I believe we
> should have a stable beta for two weeks before the
> release vote will be called, so this date is somewhat
> flexible.
>
> I volunteer to be release manager for this release.
>
> Regards
> Dmitri Plotnikov.
> dmitri@apache.org
>
> Let me start with my vote
> 1. Adopt Proposed Release Plan    [+1]
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Games - play chess, backgammon, pool and more
> http://games.yahoo.com/
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>