You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2003/05/10 01:24:40 UTC
Ant integration proposal - Summary
Hi folks,
given that it's a bit hard to follow the rapid changes I have been doing
lately in a branch of the Cactus CVS repository, I thought I'd write a
summary that provides some context and information on the proposed Ant
integration. This is rather long, so you might prefer to print it out
and lean back while reading :-)
/------------------------------------------\
| Background |
\------------------------------------------/
No released version of Cactus has a real Ant integration layer. What
exists is the well known <runservertests> task and a handful of build
file fragments that can start and stop specific containers. The
<runservertests> task exists because it makes it easier to manage the
startup/shutdown of containers before/after the Cactus tests are run. In
fact, since Ant 1.5 the same thing can be accomplished using a smart
combination of the <waitfor>/<sequential>/<parallel> tasks, although
that's a bit involved.
One problem with this situation is that the <runservertests> task
operates on a relatively low level. It only provides a basic mechanism
to run the in-container tests, without providing a good abstraction over
what's happening. In addition, it implicitly uses the core <antcall>
task to start/stop the server and run the tests, which results in build
files that tend to be procedural (as opposed to declarative, what Ant
build files are supposed to be, ideally). The use of <antcall> also
imposes a lot of runtime overhead on a build, because a target called
this way is executed as if it was directly invoked from the
command-line, i.e. all the targets it depends on are also executed. Thus
it is quite hard to achieve a well structured build with minimized build
time and a clear dependancy graph when using <runservertests>.
The other problem is that the build file fragments were made available
from the Cactus servlet-sample, and needed to be copied -- possibly
modified -- into a project that wanted to use Cactus via Ant. Obviously
this is a maintenance nightmare and requires a lot of work from
Cactus/Ant users.
/------------------------------------------\
| Recent Development |
\------------------------------------------/
A few months ago, Vincent moved the build file fragments as well as the
<runservertests> task that were a bit scattered throughout the Cactus
CVS into a new "real" Ant integration module, and cleaned it all up. The
intent was to make it unnecessary for the user to copy/integrate the
stuff from the servlet-sample into her own projects. Basically, it
should be possible to just do:
<ant dir="${cactus.install.dir}" target="test.tomcat4x">
<property name="cactus.home.tomcat4x"/>
...
</ant>
and have the tests run against Tomcat 4.x. Configuration is done via Ant
properties and references. For example, there's a property that defines
the source directory of the test code, a property for the port on which
to run the container, etc etc. Later in the game an Ant task,
<webxmlmerge>, was added to merge two deployment descriptors, used for
extending a standard web.xml with the definitions needed for the Cactus
tests.
/------------------------------------------\
| Proposal |
\------------------------------------------/
When I finally had some time to seriously play with this new integration
module, I found a couple of shortcomings as well as a general -- or call
it philosophical -- conflict with the way third-party applications and
framework usually integrate into Ant. The approach chosen seemed closer
to the plug-in model used by Maven. What I would have wanted was a JAR
containing a couple of tasks that I could use to easily integrate
Cactus-based tests into an Ant build. These tasks would hide as much as
possible from the the complex activities required to get the tests
running, but still provide great flexibility and control over how the
tests are executed.
Thus I made a proposal for a different kind of Ant integration [1]. The
proposed integration should provide full-featured tasks to accomplish a
clean integration of Cactus with Ant. The proposal has been developed in
a branch of the Cactus CVS (CACTUS_14_ANT_BRANCH), and has reached a
level of relative maturity by now. In the following, unless I explicitly
talk about the "old" Ant integration, I'm referring to the integration
module as implemented in the proposal branch.
/------------------------------------------\
| Ant Tasks |
\------------------------------------------/
The Ant integration attempts to provide solutions for two areas that are
usually difficult, error-prone and/or just annoying to implement currently:
- Cactifying a web-application
With "cactification" we mean enhancing an existing, plain
web-application with the redirectors and resources needed to run
Cactus tests. This includes adding the definitions of the Cactus
test redirectors to the deployment descriptor of the web-app, as
well as adding the libraries required by Cactus on the server-side,
and adding the JSP file for the JSP redirector.
For this purpose, the Ant ingegration defines a <cactify> task,
which can be used like this:
<cactify srcfile="myapp.war" destfile="cactustest.war">
<servletredirector mapping="/test/ServletRedirector"/>
<jspredirector mapping="/test/JspRedirector"/>
<classes dir="${test.classes.dir}" includes="**/*.class"/>
</cactify>
As you can probably see, <cactify> takes an existing WAR file as
input and generates a new, cactified WAR file. It automatically adds
the JARs required by Cactus on the server side to the cactified
WAR (they need to be on the task's classpath for this to work,
though). It also adds the jspRedirector.jsp file to the generated
WAR automatically. By default, the redirector definitions are added
to the resulting web.xml with the default mappings, but you can
override the mapping on a per-redirector basis.
In fact, the <cactify> task extends the core <war> task, so you can
specify arbitrary files to be included in the cactified WAR by using
nested <classes>, <lib>, <fileset>, <metainf> or <webinf> filesets.
This feature is used in the above example to add the test classes to
the WAR.
- Running the Cactus tests
There are two distinct parts to running Cactus tests: first, the
container to test against needs to be running, second, the tests need
to be executed by some JUnit test runner. Ant already provides an
optional, much used, <junit> task for the latter. In the past, it was
usually used in combination with the <runservertests> task and a
couple of targets that startup and shutdown containers, with all the
problems discussed further above.
The proposed integration module provides a custom <cactus> task that
extends the <junit> task with provisions for in-container tests.
Specifically, the <cactus> task takes a WAR file as input and allows
the specification of a set of containers to run the tests against.
For example, to run some tests against Tomcat 4.x and Resin 2.x the
<cactus> task could be used like this:
<cactus warfile="cactustest.war" failureproperty="tests.failed">
<containerset>
<tomcat4x dir="${tomcat4x.home}" port="8080"/>
<resinx dir="${resin2x.home}" port="8080"/>
</containerset>
<formatter type="brief" usefile="no"/>
<batchtest>
<fileset dir="${src.test.dir}" includes="**/*Test.java"/>
</batchtest>
</cactus>
Simple, no? And all in a single target. But the <cactus> task
provides more flexibility, too:
<cactus ...>
<containerset timeout="60000">
<generic port="8080" todir="${test.reports.dir}/foobar">
<startup>
<echo>Starting Foobar</echo>
<java classname="foo.bar.Main" fork="yes">
<arg value="start"/>
<arg value="-port"/>
<arg value="8080"/>
</java>
</startup>
<shutdown>
<echo>Stopping Foobar</echo>
<java classname="foo.bar.Main" fork="yes">
<arg value="stop"/>
</java>
</shutdown>
</generic>
</containerset>
...
</cactus>
So you can either test against one of the containers with built-in
support, or against some exotic or just unsupported container.
Currently, the <cactus> task supports the following containers:
- Apache Tomcat 3.x
- Apache Tomcat 4.x
- Apache Tomcat 5.x
- Caucho Resin 2.x
- Orion 1.x and 2.x
- JBoss 3.x (limited support)
(I could use some help with the WebLogic support)
As noted above, the <cactus> task takes a WAR file as input. Apart
from that WAR file being passed to the individual containers for
deployment, it is also analyzed to extract the correct settings for
the Cactus system properties. So, the mappings of the test
redirectors are retrieved from the web.xml in the test WAR and
automatically setup as the cactus.XxxRedirectorName system
properties. The cactus.contextURL is assembled from the name of
the WAR file and the specified port.
/------------------------------------------\
| Summary |
\------------------------------------------/
The proposed Ant integration module I just tried to describe has quite a
few advantages over the current integration IMHO (naturally), which I'll
try to summarize here. If you're the manager type and read all the stuff
above, I'm pleased to announce that it would have been enough to read
this section ;-)
- The proposal provides a kind of integration with Ant that Ant users
are already very familiar with. It is the standard way to integrate
with Ant builds: by providing tasks that need to be <taskdef>'d.
- It does not require the user to "install" anything, or copy files
into their project, except for the Cactus JARs.
- It's not necessary to use <antcall> (explicitly or implicitly), which
makes for shorter build execution times, cleaner dependancy graphs
and more digestable log ouput from the build. When you execute the
Cactus tests, you usually stay within a single target.
- Running the tests is less error-prone, because the web-app archive
can be automatically cactified, and the <cactus> task will
automatically extract the correct settings for the Cactus system
properties.
- Output from the containers can be redirected into a file, thus making
the actual build output easier to read.
- By using the 'proxyport' attribute of the <containerset> element, a
proxy application can be inserted between the client-side and the
server-side of Cactus tests, thus making it simpler to track down
non-obvious failures.
- Through the <generic> container element, we still provide all the
flexibility of the <runservertests> task.
- There are more (albeit still not enough) unit tests :-)
If you've come this far, it's probably time to grab a box of cookies, a
coffee or a cigarette, depending on your preferences and your current
environment. Any feedback would be most welcome. Thanks for reading!
[1] http://marc.theaimsgroup.com/?l=cactus-dev&m=105057096209634&w=2
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Ant integration proposal - Summary
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
I didn't know about the 'appserver' plug-in and the other stuff you
pointed me to. Those are some pretty good reasons for factoring out the
container support from Cactus.
Of course we should put all our energy in getting the next Cactus
release out. My personal post 1.5 priority would be J2EE 1.4 support,
but I'd also be interested in participating in a "standalone"
container-support library.
-chris
Vincent Massol wrote:
>
>>-----Original Message-----
>>From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
>>Sent: 12 May 2003 13:33
>>To: cactus-dev@jakarta.apache.org
>>Subject: Re: Ant integration proposal - Summary
>>
>
> [snip]
>
>>>In addition, a corollary is
>>>that in the near future (and if we all agree) it will be quite easy
> to
>>>extract these tasks from the Cactus project and start a new generic
>>>project (in jakarta-commons or somewhere else) which will focus
> purely
>>>on starting, stopping, configuring and deploying of containers.
> After
>>>all, what we've been doing in Cactus land is generic and not related
> to
>>>the Cactus business. We could lead the way in implementing this new
>>>project and make Cactus be the first to use it.
>>
>>I'm not sure about this. IMHO the support for starting/stopping
>>containers for performing in-container tests is very well in the scope
>>of the Cactus project. Separating this support from Cactus would be
>>quite some work, for which I don't see much benefit ATM.
>>
>>What other applications do you have in mind that could use this
>>container support? I would agree with factoring this support out of
> the
>>Cactus code-base only if there are concrete interested parties.
>
> My POV is that *every* person I've talked to is interested in having
> easy ways of starting/stopping/deploying/configuring stuff in
> containers. This doesn't currently exists. Candidates are:
> - several Maven plugins
> - Ant tasks
> - Eclipse plugins. ATM, every Eclipse plugin associated with application
> servers reinvents the wheel
> - Cactus
>
> What has already started to happen is that other projects will reinvent
> the wheel and not use the Cactus stuff because they don't care about
> cactus but do care about containers management. For example, the
> following Maven plugins
> (http://maven.apache.org/reference/plugins/index.html) are already doing
> part of what cactus is doing:
> - appserver
> - jboss
> - was40
>
> The sames applies for existing Eclipse plugins (lomboz, etc).
>
> Why would the Cactus project spend time extracting this stuff? I see the
> following reasons:
>
> 1/ if we don't do it, someone will do it, in their own way, which will
> not exactly fit cactus needs, and we will loose our invested effort.
>
> 2/ no such project exists to my knowledge
>
> 3/ It is an interesting project and making it in jakarta land has the
> possibility of this project becoming a standard
>
> 4/ I have been maintaining scripts for the different containers for 1.5
> years already and a/ I am tired of doing it alone and b/ I can't follow
> the progress of containers and c/ it will be even more difficult now
> that we are doing it in java. Thus, making this project will give it
> visibility and attract other persons interested by this subject.
>
> 5/ I don't believe in scope expansion. I like focused projects. Cactus
> is *not* about starting/stopping/deploying/configuring containers. It is
> about unit testing. Thus, this is a code smell and factoring out this
> stuff should be one of out priority. The same applies for the webapp
> Eclipse plugin BTW.
>
> 6/ Factorizing out "unneeded" stuff always lead to better design and
> reveal unnecessary dependencies. It will also make Cactus simpler to
> grasp.
>
> 7/ We can release new container support (for example) without having to
> release a new cactus version (different lifecycle). It will still work
> with existing Cactus versions.
>
> I'm not asking us to take a decision now... :-) Just think about it for
> the time being... I would love to succeed in convincing you as I would
> definitely need your help in that task if we follow this route.
>
> FWIW, I've found an email I sent to the Maven mailing lists some time
> ago on the same subject:
> http://www.mail-archive.com/cgi-bin/htsearch?method=and&format=short&con
> fig=users_maven_apache_org&restrict=&exclude=&words=Container+start%2Fst
> op+%2B+packaging
>
> Thanks
> -Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Ant integration proposal - Summary
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: 12 May 2003 13:33
> To: cactus-dev@jakarta.apache.org
> Subject: Re: Ant integration proposal - Summary
>
[snip]
> >In addition, a corollary is
> > that in the near future (and if we all agree) it will be quite easy
to
> > extract these tasks from the Cactus project and start a new generic
> > project (in jakarta-commons or somewhere else) which will focus
purely
> > on starting, stopping, configuring and deploying of containers.
After
> > all, what we've been doing in Cactus land is generic and not related
to
> > the Cactus business. We could lead the way in implementing this new
> > project and make Cactus be the first to use it.
>
> I'm not sure about this. IMHO the support for starting/stopping
> containers for performing in-container tests is very well in the scope
> of the Cactus project. Separating this support from Cactus would be
> quite some work, for which I don't see much benefit ATM.
>
> What other applications do you have in mind that could use this
> container support? I would agree with factoring this support out of
the
> Cactus code-base only if there are concrete interested parties.
>
My POV is that *every* person I've talked to is interested in having
easy ways of starting/stopping/deploying/configuring stuff in
containers. This doesn't currently exists. Candidates are:
- several Maven plugins
- Ant tasks
- Eclipse plugins. ATM, every Eclipse plugin associated with application
servers reinvents the wheel
- Cactus
What has already started to happen is that other projects will reinvent
the wheel and not use the Cactus stuff because they don't care about
cactus but do care about containers management. For example, the
following Maven plugins
(http://maven.apache.org/reference/plugins/index.html) are already doing
part of what cactus is doing:
- appserver
- jboss
- was40
The sames applies for existing Eclipse plugins (lomboz, etc).
Why would the Cactus project spend time extracting this stuff? I see the
following reasons:
1/ if we don't do it, someone will do it, in their own way, which will
not exactly fit cactus needs, and we will loose our invested effort.
2/ no such project exists to my knowledge
3/ It is an interesting project and making it in jakarta land has the
possibility of this project becoming a standard
4/ I have been maintaining scripts for the different containers for 1.5
years already and a/ I am tired of doing it alone and b/ I can't follow
the progress of containers and c/ it will be even more difficult now
that we are doing it in java. Thus, making this project will give it
visibility and attract other persons interested by this subject.
5/ I don't believe in scope expansion. I like focused projects. Cactus
is *not* about starting/stopping/deploying/configuring containers. It is
about unit testing. Thus, this is a code smell and factoring out this
stuff should be one of out priority. The same applies for the webapp
Eclipse plugin BTW.
6/ Factorizing out "unneeded" stuff always lead to better design and
reveal unnecessary dependencies. It will also make Cactus simpler to
grasp.
7/ We can release new container support (for example) without having to
release a new cactus version (different lifecycle). It will still work
with existing Cactus versions.
I'm not asking us to take a decision now... :-) Just think about it for
the time being... I would love to succeed in convincing you as I would
definitely need your help in that task if we follow this route.
FWIW, I've found an email I sent to the Maven mailing lists some time
ago on the same subject:
http://www.mail-archive.com/cgi-bin/htsearch?method=and&format=short&con
fig=users_maven_apache_org&restrict=&exclude=&words=Container+start%2Fst
op+%2B+packaging
Thanks
-Vincent
> > Thanks
> > -Vincent
>
> [snip]
>
> -chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Ant integration proposal - Summary
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
Vincent Massol wrote:
> Wow. Very nice summary! I'm impressed :-)
>
> For me your proposal has an advantage not listed down there:
>
> - It is in java and thus makes it a very good candidate for reuse by any
> other integrations, like the Eclipse plugin.
Agreed.
>In addition, a corollary is
> that in the near future (and if we all agree) it will be quite easy to
> extract these tasks from the Cactus project and start a new generic
> project (in jakarta-commons or somewhere else) which will focus purely
> on starting, stopping, configuring and deploying of containers. After
> all, what we've been doing in Cactus land is generic and not related to
> the Cactus business. We could lead the way in implementing this new
> project and make Cactus be the first to use it.
I'm not sure about this. IMHO the support for starting/stopping
containers for performing in-container tests is very well in the scope
of the Cactus project. Separating this support from Cactus would be
quite some work, for which I don't see much benefit ATM.
What other applications do you have in mind that could use this
container support? I would agree with factoring this support out of the
Cactus code-base only if there are concrete interested parties.
> Thanks
> -Vincent
[snip]
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Ant integration proposal - Summary
Posted by Vincent Massol <vm...@pivolis.com>.
Wow. Very nice summary! I'm impressed :-)
For me your proposal has an advantage not listed down there:
- It is in java and thus makes it a very good candidate for reuse by any
other integrations, like the Eclipse plugin. In addition, a corollary is
that in the near future (and if we all agree) it will be quite easy to
extract these tasks from the Cactus project and start a new generic
project (in jakarta-commons or somewhere else) which will focus purely
on starting, stopping, configuring and deploying of containers. After
all, what we've been doing in Cactus land is generic and not related to
the Cactus business. We could lead the way in implementing this new
project and make Cactus be the first to use it.
Thanks
-Vincent
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 10 May 2003 01:25
> To: Cactus Developers List; Cactus Users List
> Subject: Ant integration proposal - Summary
>
> Hi folks,
>
> given that it's a bit hard to follow the rapid changes I have been
doing
> lately in a branch of the Cactus CVS repository, I thought I'd write a
> summary that provides some context and information on the proposed Ant
> integration. This is rather long, so you might prefer to print it out
> and lean back while reading :-)
>
> /------------------------------------------\
> | Background |
> \------------------------------------------/
>
> No released version of Cactus has a real Ant integration layer. What
> exists is the well known <runservertests> task and a handful of build
> file fragments that can start and stop specific containers. The
> <runservertests> task exists because it makes it easier to manage the
> startup/shutdown of containers before/after the Cactus tests are run.
In
> fact, since Ant 1.5 the same thing can be accomplished using a smart
> combination of the <waitfor>/<sequential>/<parallel> tasks, although
> that's a bit involved.
>
> One problem with this situation is that the <runservertests> task
> operates on a relatively low level. It only provides a basic mechanism
> to run the in-container tests, without providing a good abstraction
over
> what's happening. In addition, it implicitly uses the core <antcall>
> task to start/stop the server and run the tests, which results in
build
> files that tend to be procedural (as opposed to declarative, what Ant
> build files are supposed to be, ideally). The use of <antcall> also
> imposes a lot of runtime overhead on a build, because a target called
> this way is executed as if it was directly invoked from the
> command-line, i.e. all the targets it depends on are also executed.
Thus
> it is quite hard to achieve a well structured build with minimized
build
> time and a clear dependancy graph when using <runservertests>.
>
> The other problem is that the build file fragments were made available
> from the Cactus servlet-sample, and needed to be copied -- possibly
> modified -- into a project that wanted to use Cactus via Ant.
Obviously
> this is a maintenance nightmare and requires a lot of work from
> Cactus/Ant users.
>
> /------------------------------------------\
> | Recent Development |
> \------------------------------------------/
>
> A few months ago, Vincent moved the build file fragments as well as
the
> <runservertests> task that were a bit scattered throughout the Cactus
> CVS into a new "real" Ant integration module, and cleaned it all up.
The
> intent was to make it unnecessary for the user to copy/integrate the
> stuff from the servlet-sample into her own projects. Basically, it
> should be possible to just do:
>
> <ant dir="${cactus.install.dir}" target="test.tomcat4x">
> <property name="cactus.home.tomcat4x"/>
> ...
> </ant>
>
> and have the tests run against Tomcat 4.x. Configuration is done via
Ant
> properties and references. For example, there's a property that
defines
> the source directory of the test code, a property for the port on
which
> to run the container, etc etc. Later in the game an Ant task,
> <webxmlmerge>, was added to merge two deployment descriptors, used for
> extending a standard web.xml with the definitions needed for the
Cactus
> tests.
>
> /------------------------------------------\
> | Proposal |
> \------------------------------------------/
>
> When I finally had some time to seriously play with this new
integration
> module, I found a couple of shortcomings as well as a general -- or
call
> it philosophical -- conflict with the way third-party applications and
> framework usually integrate into Ant. The approach chosen seemed
closer
> to the plug-in model used by Maven. What I would have wanted was a JAR
> containing a couple of tasks that I could use to easily integrate
> Cactus-based tests into an Ant build. These tasks would hide as much
as
> possible from the the complex activities required to get the tests
> running, but still provide great flexibility and control over how the
> tests are executed.
>
> Thus I made a proposal for a different kind of Ant integration [1].
The
> proposed integration should provide full-featured tasks to accomplish
a
> clean integration of Cactus with Ant. The proposal has been developed
in
> a branch of the Cactus CVS (CACTUS_14_ANT_BRANCH), and has reached a
> level of relative maturity by now. In the following, unless I
explicitly
> talk about the "old" Ant integration, I'm referring to the integration
> module as implemented in the proposal branch.
>
> /------------------------------------------\
> | Ant Tasks |
> \------------------------------------------/
>
> The Ant integration attempts to provide solutions for two areas that
are
> usually difficult, error-prone and/or just annoying to implement
> currently:
>
> - Cactifying a web-application
>
> With "cactification" we mean enhancing an existing, plain
> web-application with the redirectors and resources needed to run
> Cactus tests. This includes adding the definitions of the Cactus
> test redirectors to the deployment descriptor of the web-app, as
> well as adding the libraries required by Cactus on the
server-side,
> and adding the JSP file for the JSP redirector.
>
> For this purpose, the Ant ingegration defines a <cactify> task,
> which can be used like this:
>
> <cactify srcfile="myapp.war" destfile="cactustest.war">
> <servletredirector mapping="/test/ServletRedirector"/>
> <jspredirector mapping="/test/JspRedirector"/>
> <classes dir="${test.classes.dir}" includes="**/*.class"/>
> </cactify>
>
> As you can probably see, <cactify> takes an existing WAR file as
> input and generates a new, cactified WAR file. It automatically
adds
> the JARs required by Cactus on the server side to the cactified
> WAR (they need to be on the task's classpath for this to work,
> though). It also adds the jspRedirector.jsp file to the generated
> WAR automatically. By default, the redirector definitions are
added
> to the resulting web.xml with the default mappings, but you can
> override the mapping on a per-redirector basis.
>
> In fact, the <cactify> task extends the core <war> task, so you
can
> specify arbitrary files to be included in the cactified WAR by
using
> nested <classes>, <lib>, <fileset>, <metainf> or <webinf>
filesets.
> This feature is used in the above example to add the test classes
to
> the WAR.
>
> - Running the Cactus tests
>
> There are two distinct parts to running Cactus tests: first, the
> container to test against needs to be running, second, the tests
need
> to be executed by some JUnit test runner. Ant already provides an
> optional, much used, <junit> task for the latter. In the past, it
was
> usually used in combination with the <runservertests> task and a
> couple of targets that startup and shutdown containers, with all
the
> problems discussed further above.
>
> The proposed integration module provides a custom <cactus> task
that
> extends the <junit> task with provisions for in-container tests.
> Specifically, the <cactus> task takes a WAR file as input and
allows
> the specification of a set of containers to run the tests against.
>
> For example, to run some tests against Tomcat 4.x and Resin 2.x
the
> <cactus> task could be used like this:
>
> <cactus warfile="cactustest.war" failureproperty="tests.failed">
> <containerset>
> <tomcat4x dir="${tomcat4x.home}" port="8080"/>
> <resinx dir="${resin2x.home}" port="8080"/>
> </containerset>
> <formatter type="brief" usefile="no"/>
> <batchtest>
> <fileset dir="${src.test.dir}" includes="**/*Test.java"/>
> </batchtest>
> </cactus>
>
> Simple, no? And all in a single target. But the <cactus> task
> provides more flexibility, too:
>
> <cactus ...>
> <containerset timeout="60000">
> <generic port="8080" todir="${test.reports.dir}/foobar">
> <startup>
> <echo>Starting Foobar</echo>
> <java classname="foo.bar.Main" fork="yes">
> <arg value="start"/>
> <arg value="-port"/>
> <arg value="8080"/>
> </java>
> </startup>
> <shutdown>
> <echo>Stopping Foobar</echo>
> <java classname="foo.bar.Main" fork="yes">
> <arg value="stop"/>
> </java>
> </shutdown>
> </generic>
> </containerset>
> ...
> </cactus>
>
> So you can either test against one of the containers with
built-in
> support, or against some exotic or just unsupported container.
> Currently, the <cactus> task supports the following containers:
>
> - Apache Tomcat 3.x
> - Apache Tomcat 4.x
> - Apache Tomcat 5.x
> - Caucho Resin 2.x
> - Orion 1.x and 2.x
> - JBoss 3.x (limited support)
>
> (I could use some help with the WebLogic support)
>
> As noted above, the <cactus> task takes a WAR file as input.
Apart
> from that WAR file being passed to the individual containers for
> deployment, it is also analyzed to extract the correct settings
for
> the Cactus system properties. So, the mappings of the test
> redirectors are retrieved from the web.xml in the test WAR and
> automatically setup as the cactus.XxxRedirectorName system
> properties. The cactus.contextURL is assembled from the name of
> the WAR file and the specified port.
>
> /------------------------------------------\
> | Summary |
> \------------------------------------------/
>
> The proposed Ant integration module I just tried to describe has quite
a
> few advantages over the current integration IMHO (naturally), which
I'll
> try to summarize here. If you're the manager type and read all the
stuff
> above, I'm pleased to announce that it would have been enough to read
> this section ;-)
>
> - The proposal provides a kind of integration with Ant that Ant
users
> are already very familiar with. It is the standard way to
integrate
> with Ant builds: by providing tasks that need to be <taskdef>'d.
>
> - It does not require the user to "install" anything, or copy files
> into their project, except for the Cactus JARs.
>
> - It's not necessary to use <antcall> (explicitly or implicitly),
which
> makes for shorter build execution times, cleaner dependancy graphs
> and more digestable log ouput from the build. When you execute the
> Cactus tests, you usually stay within a single target.
>
> - Running the tests is less error-prone, because the web-app archive
> can be automatically cactified, and the <cactus> task will
> automatically extract the correct settings for the Cactus system
> properties.
>
> - Output from the containers can be redirected into a file, thus
making
> the actual build output easier to read.
>
> - By using the 'proxyport' attribute of the <containerset> element,
a
> proxy application can be inserted between the client-side and the
> server-side of Cactus tests, thus making it simpler to track down
> non-obvious failures.
>
> - Through the <generic> container element, we still provide all the
> flexibility of the <runservertests> task.
>
> - There are more (albeit still not enough) unit tests :-)
>
>
> If you've come this far, it's probably time to grab a box of cookies,
a
> coffee or a cigarette, depending on your preferences and your current
> environment. Any feedback would be most welcome. Thanks for reading!
>
>
> [1] http://marc.theaimsgroup.com/?l=cactus-dev&m=105057096209634&w=2
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
RE: Ant integration proposal - Summary
Posted by Vincent Massol <vm...@pivolis.com>.
Wow. Very nice summary! I'm impressed :-)
For me your proposal has an advantage not listed down there:
- It is in java and thus makes it a very good candidate for reuse by any
other integrations, like the Eclipse plugin. In addition, a corollary is
that in the near future (and if we all agree) it will be quite easy to
extract these tasks from the Cactus project and start a new generic
project (in jakarta-commons or somewhere else) which will focus purely
on starting, stopping, configuring and deploying of containers. After
all, what we've been doing in Cactus land is generic and not related to
the Cactus business. We could lead the way in implementing this new
project and make Cactus be the first to use it.
Thanks
-Vincent
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 10 May 2003 01:25
> To: Cactus Developers List; Cactus Users List
> Subject: Ant integration proposal - Summary
>
> Hi folks,
>
> given that it's a bit hard to follow the rapid changes I have been
doing
> lately in a branch of the Cactus CVS repository, I thought I'd write a
> summary that provides some context and information on the proposed Ant
> integration. This is rather long, so you might prefer to print it out
> and lean back while reading :-)
>
> /------------------------------------------\
> | Background |
> \------------------------------------------/
>
> No released version of Cactus has a real Ant integration layer. What
> exists is the well known <runservertests> task and a handful of build
> file fragments that can start and stop specific containers. The
> <runservertests> task exists because it makes it easier to manage the
> startup/shutdown of containers before/after the Cactus tests are run.
In
> fact, since Ant 1.5 the same thing can be accomplished using a smart
> combination of the <waitfor>/<sequential>/<parallel> tasks, although
> that's a bit involved.
>
> One problem with this situation is that the <runservertests> task
> operates on a relatively low level. It only provides a basic mechanism
> to run the in-container tests, without providing a good abstraction
over
> what's happening. In addition, it implicitly uses the core <antcall>
> task to start/stop the server and run the tests, which results in
build
> files that tend to be procedural (as opposed to declarative, what Ant
> build files are supposed to be, ideally). The use of <antcall> also
> imposes a lot of runtime overhead on a build, because a target called
> this way is executed as if it was directly invoked from the
> command-line, i.e. all the targets it depends on are also executed.
Thus
> it is quite hard to achieve a well structured build with minimized
build
> time and a clear dependancy graph when using <runservertests>.
>
> The other problem is that the build file fragments were made available
> from the Cactus servlet-sample, and needed to be copied -- possibly
> modified -- into a project that wanted to use Cactus via Ant.
Obviously
> this is a maintenance nightmare and requires a lot of work from
> Cactus/Ant users.
>
> /------------------------------------------\
> | Recent Development |
> \------------------------------------------/
>
> A few months ago, Vincent moved the build file fragments as well as
the
> <runservertests> task that were a bit scattered throughout the Cactus
> CVS into a new "real" Ant integration module, and cleaned it all up.
The
> intent was to make it unnecessary for the user to copy/integrate the
> stuff from the servlet-sample into her own projects. Basically, it
> should be possible to just do:
>
> <ant dir="${cactus.install.dir}" target="test.tomcat4x">
> <property name="cactus.home.tomcat4x"/>
> ...
> </ant>
>
> and have the tests run against Tomcat 4.x. Configuration is done via
Ant
> properties and references. For example, there's a property that
defines
> the source directory of the test code, a property for the port on
which
> to run the container, etc etc. Later in the game an Ant task,
> <webxmlmerge>, was added to merge two deployment descriptors, used for
> extending a standard web.xml with the definitions needed for the
Cactus
> tests.
>
> /------------------------------------------\
> | Proposal |
> \------------------------------------------/
>
> When I finally had some time to seriously play with this new
integration
> module, I found a couple of shortcomings as well as a general -- or
call
> it philosophical -- conflict with the way third-party applications and
> framework usually integrate into Ant. The approach chosen seemed
closer
> to the plug-in model used by Maven. What I would have wanted was a JAR
> containing a couple of tasks that I could use to easily integrate
> Cactus-based tests into an Ant build. These tasks would hide as much
as
> possible from the the complex activities required to get the tests
> running, but still provide great flexibility and control over how the
> tests are executed.
>
> Thus I made a proposal for a different kind of Ant integration [1].
The
> proposed integration should provide full-featured tasks to accomplish
a
> clean integration of Cactus with Ant. The proposal has been developed
in
> a branch of the Cactus CVS (CACTUS_14_ANT_BRANCH), and has reached a
> level of relative maturity by now. In the following, unless I
explicitly
> talk about the "old" Ant integration, I'm referring to the integration
> module as implemented in the proposal branch.
>
> /------------------------------------------\
> | Ant Tasks |
> \------------------------------------------/
>
> The Ant integration attempts to provide solutions for two areas that
are
> usually difficult, error-prone and/or just annoying to implement
> currently:
>
> - Cactifying a web-application
>
> With "cactification" we mean enhancing an existing, plain
> web-application with the redirectors and resources needed to run
> Cactus tests. This includes adding the definitions of the Cactus
> test redirectors to the deployment descriptor of the web-app, as
> well as adding the libraries required by Cactus on the
server-side,
> and adding the JSP file for the JSP redirector.
>
> For this purpose, the Ant ingegration defines a <cactify> task,
> which can be used like this:
>
> <cactify srcfile="myapp.war" destfile="cactustest.war">
> <servletredirector mapping="/test/ServletRedirector"/>
> <jspredirector mapping="/test/JspRedirector"/>
> <classes dir="${test.classes.dir}" includes="**/*.class"/>
> </cactify>
>
> As you can probably see, <cactify> takes an existing WAR file as
> input and generates a new, cactified WAR file. It automatically
adds
> the JARs required by Cactus on the server side to the cactified
> WAR (they need to be on the task's classpath for this to work,
> though). It also adds the jspRedirector.jsp file to the generated
> WAR automatically. By default, the redirector definitions are
added
> to the resulting web.xml with the default mappings, but you can
> override the mapping on a per-redirector basis.
>
> In fact, the <cactify> task extends the core <war> task, so you
can
> specify arbitrary files to be included in the cactified WAR by
using
> nested <classes>, <lib>, <fileset>, <metainf> or <webinf>
filesets.
> This feature is used in the above example to add the test classes
to
> the WAR.
>
> - Running the Cactus tests
>
> There are two distinct parts to running Cactus tests: first, the
> container to test against needs to be running, second, the tests
need
> to be executed by some JUnit test runner. Ant already provides an
> optional, much used, <junit> task for the latter. In the past, it
was
> usually used in combination with the <runservertests> task and a
> couple of targets that startup and shutdown containers, with all
the
> problems discussed further above.
>
> The proposed integration module provides a custom <cactus> task
that
> extends the <junit> task with provisions for in-container tests.
> Specifically, the <cactus> task takes a WAR file as input and
allows
> the specification of a set of containers to run the tests against.
>
> For example, to run some tests against Tomcat 4.x and Resin 2.x
the
> <cactus> task could be used like this:
>
> <cactus warfile="cactustest.war" failureproperty="tests.failed">
> <containerset>
> <tomcat4x dir="${tomcat4x.home}" port="8080"/>
> <resinx dir="${resin2x.home}" port="8080"/>
> </containerset>
> <formatter type="brief" usefile="no"/>
> <batchtest>
> <fileset dir="${src.test.dir}" includes="**/*Test.java"/>
> </batchtest>
> </cactus>
>
> Simple, no? And all in a single target. But the <cactus> task
> provides more flexibility, too:
>
> <cactus ...>
> <containerset timeout="60000">
> <generic port="8080" todir="${test.reports.dir}/foobar">
> <startup>
> <echo>Starting Foobar</echo>
> <java classname="foo.bar.Main" fork="yes">
> <arg value="start"/>
> <arg value="-port"/>
> <arg value="8080"/>
> </java>
> </startup>
> <shutdown>
> <echo>Stopping Foobar</echo>
> <java classname="foo.bar.Main" fork="yes">
> <arg value="stop"/>
> </java>
> </shutdown>
> </generic>
> </containerset>
> ...
> </cactus>
>
> So you can either test against one of the containers with
built-in
> support, or against some exotic or just unsupported container.
> Currently, the <cactus> task supports the following containers:
>
> - Apache Tomcat 3.x
> - Apache Tomcat 4.x
> - Apache Tomcat 5.x
> - Caucho Resin 2.x
> - Orion 1.x and 2.x
> - JBoss 3.x (limited support)
>
> (I could use some help with the WebLogic support)
>
> As noted above, the <cactus> task takes a WAR file as input.
Apart
> from that WAR file being passed to the individual containers for
> deployment, it is also analyzed to extract the correct settings
for
> the Cactus system properties. So, the mappings of the test
> redirectors are retrieved from the web.xml in the test WAR and
> automatically setup as the cactus.XxxRedirectorName system
> properties. The cactus.contextURL is assembled from the name of
> the WAR file and the specified port.
>
> /------------------------------------------\
> | Summary |
> \------------------------------------------/
>
> The proposed Ant integration module I just tried to describe has quite
a
> few advantages over the current integration IMHO (naturally), which
I'll
> try to summarize here. If you're the manager type and read all the
stuff
> above, I'm pleased to announce that it would have been enough to read
> this section ;-)
>
> - The proposal provides a kind of integration with Ant that Ant
users
> are already very familiar with. It is the standard way to
integrate
> with Ant builds: by providing tasks that need to be <taskdef>'d.
>
> - It does not require the user to "install" anything, or copy files
> into their project, except for the Cactus JARs.
>
> - It's not necessary to use <antcall> (explicitly or implicitly),
which
> makes for shorter build execution times, cleaner dependancy graphs
> and more digestable log ouput from the build. When you execute the
> Cactus tests, you usually stay within a single target.
>
> - Running the tests is less error-prone, because the web-app archive
> can be automatically cactified, and the <cactus> task will
> automatically extract the correct settings for the Cactus system
> properties.
>
> - Output from the containers can be redirected into a file, thus
making
> the actual build output easier to read.
>
> - By using the 'proxyport' attribute of the <containerset> element,
a
> proxy application can be inserted between the client-side and the
> server-side of Cactus tests, thus making it simpler to track down
> non-obvious failures.
>
> - Through the <generic> container element, we still provide all the
> flexibility of the <runservertests> task.
>
> - There are more (albeit still not enough) unit tests :-)
>
>
> If you've come this far, it's probably time to grab a box of cookies,
a
> coffee or a cigarette, depending on your preferences and your current
> environment. Any feedback would be most welcome. Thanks for reading!
>
>
> [1] http://marc.theaimsgroup.com/?l=cactus-dev&m=105057096209634&w=2
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org