let me first say that I'm quite excited to see the Eclipse integration happen... I might even be able to contribute stuff here and there ;-)
The plan looks good so far, however I'm unsure about one point: what role is Ant supposed to play in the plugin? You mentioned that you are planning to use Ant scripts to start/stop the container(s), and to package the WAR.
I believe that it might be better not to depend on Ant for that. As an alternative, the Cactus plugin could expose a "Container-Provider" extension point, so that support for specific containers would actually be plugins to the Cactus plugin. That would probably allow more precise control over the container, and would reduce potential problems that could stem from the extra indirection through Ant. Container providers could (in theory, at least) maintain the support for their specific containers, while Cactus would only need to support Tomcat (for example). IMHO, that approach would be both simpler and provide more flexibility. But maybe I'm missing something ;-).
WAR creation should also not require Ant. It would, however, require a decent UI (possible a page in the project properties) to configure the layout and contents of the archive.
Thoughts?
[EMAIL PROTECTED] wrote:
vmassol 2002/10/19 06:42:21
Added: Eclipse-Plugin PLAN.txt
Log:
proposed plan (awaiting comments ;-))
Revision Changes Path
1.1 jakarta-cactus/Eclipse-Plugin/PLAN.txt
Index: PLAN.txt
===================================================================
Milestone 1 (tentative date: 22/10/2002)
----------------------------------------
Goal: Get a minimalistic Cactus plugin working with hard coded values. This includes:
- a minimalistic launch configuration
- a minimalistic launch shortcut
- a minimalistic launch configuration tab group
- no preference page
- the cactus libraries are part of the Cactus plugin
How do we test if it works? By manually starting a simple application WAR *outside* the IDE using Tomcat 4.x and by running *from the IDE* a simple cactus test for that simple application. This will prove our launch configuration is set up correctly (classpath + VM parameters).
Milestone 2 (tentative date: 25/10/2002)
----------------------------------------
Goal: Validate calling Ant script before and after running the tests to package and deploy the application to the container and start it.
Execute the Cactus Ant script for Tomcat before starting the JUnit Test Runner (and after). This Ant script needs to be part of the Cactus plugin and does the following: creates a WAR from the application sources and start Tomcat. After the test is finished a second script is run to stop Tomcat.
Milestone completes the proof of concept. It is works well, our plugin will be a success ... :-)
Milestone 3 (no date defined yet)
---------------------------------
Goal: Make the plugin ready for use.
We will need:
- Add a Cactus preference page (see below for content)
- Support for several containers. This will need to be specified both in the prefence page (default container to use) and in the Cactus TabGroup page (container to use for that test).
- On preference page and on Cactus TabGroup page: ability to choose the port on which the container is started.
- On preference page, ability to specify the working directory where the Cactus plugin will create all its files (packaged war, app server config files, etc)
- Minimal plugin documentation
Milestone 4 (no date defined yet)
---------------------------------
Goal: Improved usability and build improvements
- Ability to leave the server running after the test is finished so that we don�t need to start it again for the next test (needs hot redeploy)
- Find a way to automate building the Cactus plugin (using Ant) from outside Eclipse and make it part of the Gump runs
- Add full plugin documentation and development documentation (for todos, etc)
-- Christopher Lenz /=/ cmlenz at gmx.de
-- To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>
