vmassol 2002/12/15 03:53:36
Modified: documentation/docs/xdocs book.xml
Added: documentation/docs/xdocs eclipse_plugin.xml
Removed: documentation/docs/xdocs eclipse-plugin.xml
Log:
renamed eclise plugin xml doc from eclipse-plugin.xml to eclipse_plugin.xml to
follow existing convention
Revision Changes Path
1.20 +1 -1 jakarta-cactus/documentation/docs/xdocs/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/book.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- book.xml 14 Nov 2002 11:17:04 -0000 1.19
+++ book.xml 15 Dec 2002 11:53:36 -0000 1.20
@@ -33,7 +33,7 @@
<menu-item type="hidden" source="javadoc_12.xml"/>
<menu-item type="hidden" source="javadoc_13.xml"/>
<menu-item label="FAQ" source="faq.xml"/>
- <menu-item label="Eclipse plugin" source="eclipse-plugin.xml"/>
+ <menu-item label="Eclipse plugin" source="eclipse_plugin.xml"/>
</menu>
<menu label="Howto Guides">
1.1 jakarta-cactus/documentation/docs/xdocs/eclipse_plugin.xml
Index: eclipse_plugin.xml
===================================================================
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl"
href="./skins/jakarta.apache.org/stylesheets/document2html.xsl"?>
<document>
<header>
<title>Architecture of the Eclipse Plugin for Cactus</title>
<authors>
<person name="Julien Ruaux" email="[EMAIL PROTECTED]" />
</authors>
</header>
<body>
<s1 title="Overview">
<p>
Cactus uses and extends JUnit. It might then seem natural
that the Cactus plugin for Eclipse extends in a certain manner
the existing JUnit plugin. For example
<code>JUnitLaunchShortcut</code>
is overloaded to be able to :
</p>
<ul>
<li>
prepare tests : setup of the container (deployment)
and startup
</li>
<li>
execute tests using the JUnit plugin methods
</li>
<li>
tear down tests : stop the container and clean the
deployment.
</li>
</ul>
<p>
In its actual state the plugin uses Ant scripts for these
container setup and teardown.
</p>
</s1>
<s1 title="How it works">
<s2 title="Extension points">
<ul>
<li>
<em>
org.eclipse.debug.core.launchConfigurationTypes
</em>
registers cactusLaunchConfiguration
</li>
<li>
<em>
org.eclipse.debug.ui.launchShortcuts
</em>
registers a shortcut which appears in the run
and debug cascade menus to launch the current workbench
selection in the Java perspective
</li>
<li>
<em>
org.eclipse.ui.preferencePages
</em>
adds the Cactus preference page to the preferences.
</li>
</ul>
</s2>
<s2 title="GUI : preference page">
<p>
A preference page is contributed to the Eclipse
preferences. It shows the following entries :
</p>
<ul>
<li>
Cactus properties (contextURL)
</li>
<li>
directory of all the jars needed for Cactus
tests (client side and server side)
</li>
<li>
setting of the container homes
</li>
</ul>
</s2>
<s2 title="IContainerProvider">
<p>
To enable different ways to setup, start, and stop
containers the idea of container providers has been
introduced in the plugin.
</p>
<p>
A container provider is responsible for deploying a web
application to the container, starting and stopping it, and
undeploying the web app. This concept is concretized in the
interface
<code>IContainerProvider</code>
. See its javadoc for more information.
</p>
<p>
A container provider is implemented in the current version
of the plugin, which uses Ant scripts to carry out these
actions. It is called
<code>GenericAntProvider</code>
and may be used to execute tests on Tomcat 4.0 and
Weblogic 7.0.
</p>
</s2>
<s2 title="What happens when a test is launched">
<p>
The
<code>
launch(IType theType, String theMode)
</code>
method of the
<code>CactusLaunchShortcut</code>
class is called, which sets up the container, launches
the tests by delegating these to the JUnit plugin, and then
tears down the container setup.
</p>
<ul>
<li>
Tests preparation
<p>
This includes :
</p>
<ul>
<li>
creating the war file for the cactus
tests : this is done by the
<code>
WarBuilder
</code>
class, and relies on an Ant script for
that.
</li>
<li>
setting up the container : prepares the
configuration for the selected container
</li>
<li>
starting the container.
</li>
</ul>
<p>
In the case of
<code>
GenericAntProvider
</code>
:
</p>
<ul>
<li>
setting up is done by an Ant script
</li>
<li>
starting the container is delegated to
the
<code>
StartServerHelper
</code>
class, which initiates a thread starting
the container and then pings it constantly to
see if it has been effectively launched.
</li>
</ul>
</li>
<li>
Tests launch
<p>
This behaviour is inherited from the JUnit
plugin since
<code>
CactusLaunchShortcut
</code>
extends
<code>
JUnitLaunchShortcut
</code>
.
</p>
</li>
<li>
Tests end
<p>
To know when tests have ended we register our
TestListener to the JUnit plugin.
</p>
<p>
For that the JUnit plugin had to be modified, a
patch is avaible at the root of the Cactus CVS.
</p>
<p>
The
<code>
JUnitViewFinder
</code>
class is launched which looks for the
JUnitView, so that we can eventually register our
listener.
</p>
</li>
<li>
Tests environment cleaning
<p>
After the tests have completed, work has to be
done to stop the container and delete all
configuration files and the war file we created
before.
</p>
</li>
</ul>
</s2>
</s1>
<s1 title="What has been done so far">
<p>
In its actual state the plugin is a proof of concept. It is
able to run the distribution sample tests.
</p>
</s1>
<s1 title="What is next">
<p>
In order to have a production-quality tool the following
points must be done :
</p>
<ul>
<li>
integrate the plugin to the Cactus build process
</li>
<li>automate tests on the plugin</li>
<li>
ability to leave the container running between
redeployments
</li>
<li>
the user must be able to provide its own web.xml file.
Otherwise the plugin will use the one provided by default.
</li>
</ul>
</s1>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
