jruaux 2003/01/03 05:22:16 Modified: documentation/docs/xdocs eclipse_plugin.xml Log: Formatted to 2-space tab Revision Changes Path 1.2 +194 -241 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.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- eclipse_plugin.xml 15 Dec 2002 11:53:36 -0000 1.1 +++ eclipse_plugin.xml 3 Jan 2003 13:22:16 -0000 1.2 @@ -2,246 +2,199 @@ <?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> + <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> + </s1> + </body> </document>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
