vmassol 2003/01/03 05:42:46 Modified: documentation/docs/xdocs eclipse_plugin.xml Log: Replaced Stylebook by straight XSL Revision Changes Path 1.3 +242 -195 jakarta-cactus/documentation/docs/xdocs/eclipse_plugin.xml Index: eclipse_plugin.xml =================================================================== RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/eclipse_plugin.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- eclipse_plugin.xml 3 Jan 2003 13:22:16 -0000 1.2 +++ eclipse_plugin.xml 3 Jan 2003 13:42:46 -0000 1.3 @@ -1,200 +1,247 @@ <?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> + <properties> + <title>Architecture of the Eclipse Plugin for Cactus</title> + <authors> + <author name="Julien Ruaux" email="[EMAIL PROTECTED]"/> + </authors> + </properties> + + <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]>
