thanks for the detailled response!
I haven't yet looked at the deployment JSR, it'll be another point on my list of specs to look at ;-). However, I didn't want to suggest that the Cactus-Eclipse plugin should define an API for servlet container interaction in general, but just an extension point for the features that Cactus needs (i.e. start an 'empty' container, deploy the war, stop/cleanup the container). Roughly:
public interface IContainerProvider {
public void startUp(config);
public void deploy(webapp);
public void shutDown();
}
I agree that writing Ant scripts is easier than coding Eclipse plugins, but using the extension point approach doesn't preclude using the existing Ant Scripts. There could be a ContainerProvider implementation that just used Ant under the hoods. All the functionality existing in the Ant scripts would become instantly availabe in the Cactus plugin, *but* better container integration could also be provided if someone does the work.
In conclusion, the two approaches are not mutually exclusive IMHO. I guess I've just always considered the Ant scripts the least elegant (albeit very effective!) part of Cactus. And I've never been quite happy with the Ant support in Eclipse...
Anyway, I'll be upgrading to Eclipse 2.1 and trying to build the plugin... ;-)
Vincent Massol wrote:
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 wouldactuallybe plugins to the Cactus plugin. That would probably allow moreprecisecontrol 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!
-Vincen
-- 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>
