jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Neat Tomcat Integration + proposal for CactusServletTestRunner
Date Tue, 14 May 2002 06:55:56 GMT


> -----Original Message-----
> From: Brekke, Jeff [mailto:Jeff.Brekke@qg.com]
> Sent: 14 May 2002 04:41
> To: 'Cactus Users List'
> Subject: RE: Neat Tomcat Integration + proposal for
> CactusServletTestRunner
> 
> [SNIPPED]
> 
> > I can think of 2 solutions :
> >
> > 1/ Maven does not provide any help for the Ant scripts to start the
> > different containers (i.e. it does not provide them at all).
> > Maven users
> > have to provide them.
> >
> > 2/ Maven "knows" about Cactus and make it a first class
> > citizen (in the
> > same way that JUnit is a first class citizen) and provide
> > full support.
> > It is the easiest for users. The nice thing about the Cactus way of
> > starting application servers is that it start them in its own
> > directory
> > and does not modify any file outside of this tmp directory. This is
of
> > course my preferred solution :-)
> 
> I agree.  Maybe with the recent movement to maven plugins we can have
a
> cactus plugin.  The plugins are relatively new in Maven and I have to
> catch
> up on them myself.
> 

Excellent idea ! I think a maven cactus plugin is exactly what we need.
Once the plugin structure is stabilized, we can write it and I can host
it within Cactus as a subproject (so that it is always up to date with
cactus source code).

> > Another idea is to reuse some cactus scripts and provide some maven
> > targets maven:start-tomcat-4, etc to automatically start different
> > servlet containers. This could also be useful outside of Cactus
tests.
> > Until we get that JSR for J2EE deployments ... in about 2
> > years (that's
> > the time before all application servers implement it) :-)
> >
> > In conclusion I would be in favor of having a specific <cactus> or
> > <cactustest> tag (instead of the "generic" <iutest> one which is not
> > really generic and I don't think can be as the situation are too
> > different).
> 
> I agree that Integration Unit Tests ( iutests ) is too broad a
definition
> for just cactus tests.  I'd like to include any unit test that has a
> dependency on an external resource(s) ( or even slow unit tests ) to
be in
> the <iutest> set of tests, cactus included ( if this description
sounds
> familiar, it was you who originally helped me understand the
Integration
> Unit Test term on irc, thanks! ).
> 

:-)

> It may not be possible, but the cactus definition of tests is how I
> usually
> breakdown the testing of my projects now  (I'm not using maven for
some
> projects because it lacks this ability currently).  Unit tests (
logical
> ),
> Integration Unit Tests ( external resources, slow running tests ), and
> Customer Tests ( black box functional type tests.  Httpunit mostly. ).
I
> have all unit tests run every time the jar is built ( this is
currently
> Maven's behavior also ).  

Same for me. I have a target for each kind of tests but the "dist"
target runs them all.

> iutests and customer tests are independent
> targets.  So selfishly I want to have maven provide same partitioning.
> 
> [MORE SNIPPED]
> 
> > > On an aside, it would be interesting if we could find a way
> > to use the
> > ant
> > > build scripts to test our projects directly from cactus
> > without having
> > to
> > > integrate them into our projects build scripts ( or maybe
> > this is now
> > > possible? ).
> >
> > I think you lost me ... Can you explain slowly for me ? :-)
> 
> I mean effectively what you mention above.  The ant build scripts to
start
> the servlet containers and run the tests are already setup in the
cactus
> distribution.  I was thinking it would be sweet if we could reuse
these in
> some fashion from within the maven plugin.  Maybe read them right out
of
> the
> cactus jar or something if that's possible.
> Hmm.  It is sort of sounding like a maven wrapper around the cactus
ant
> files.  I may be way off there, thinking out loud really.
>

Ah I get it. Yes, you're absolutely right. For the moment Cactus only
provides these scripts as part of the sample application. The plugin
would wrap them nicely and make them available as a directly usable end
product for cactus and maven users. Cool.

Thanks for a good idea ! Now we need to understand the plugin structure
and we can start coding :-)

-Vincent
 
> =================================================================
> Jeffrey D. Brekke                                   Quad/Graphics
> Jeff.Brekke@qg.com                              http://www.qg.com
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message