Hi Christopher! > -----Original Message----- > From: Christopher Lenz [mailto:cmlenz@;gmx.de] > Sent: 20 October 2002 16:22 > To: Cactus Developers List > Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt > > Vincent, > > 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 ;-)
wow. Very cool. Feel free to jump in at any time :-). We need help! Just asking questions like this one is of great help. Please be sure to continue that! :-) > > 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? Ant may not be the best in term of pure architecture point of view. Agreed. However, I wanted to use it for the following reasons: - the scripts are already there in Cactus and they support about 10 or more containers. - writing 10 plugins, one for each container will take a lifetime or close to it - if you wish to be able to use the Cactus plugin within the next 5 years don't count on container implementers all flocking to the cactus web site and asking us if they can implement our nice container extension point ! :-) That said, if Eclipse were to write one as part of Eclipse, that would have some weights. But even then, it would also take at least one year to get the major containers to implement it. - in the near future, JSR 107 (http://java.sun.com/j2ee/tools/deployment) will get implemented by more and more container implementers. Once this happens writing such an extension point will make sense. It is the goal of Cactus to move to JSR 107 as soon as someone starts implementing it! :-) - Ant provides a flexible and extensible way of doing build actions (which is what we're doing : package a war, configure a container, deploy the war, start the service, stop the service, etc). It means the Cactus plugin will allow users to provide other Ant scriptlets for any other container *very* easily. And if it takes another build step for one container, no problem as all the build stuff is contained in the Ant script. No need to changed the extension point API. And most importantly anyone who knows java can write Ant build scripts. I don't think it is yet the same when it comes to write Eclipse plugins (the day may come ;-)). These were the main reasons I wanted to use Ant. That said, I am completely open to better alternative. Hey, I don't even know if it's going to work using Ant (it will work but will it be usable in practice - too slow, etc?). This is the reason for milestone 2. A POC. If it doesn't work, we'll have to try something else. To summarise, you are completely right. From an architecture point of view, it is much much better to write a container extension point. In addition it provides great reusability for other plugins. In practice, I don't currently have enough time and power to try to gather all container plugin implementers, grab the Eclipse board and start a new technology project within Eclipse to do that. I'm 100% sure someone will do it when JSR 107 matures a bit more (probably within a 6 month time frame I would say). I would prefer Cactus to remain focused on unit testing as much as possible and then migrate to use this new extension point/plugin when it becomes available. What do you think? Does it make sense? Thanks a lot for your interest! Please keep asking! -Vincent > > [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- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>
