> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@;gmx.de]
> Sent: 20 October 2002 17:56
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> Vincent,
>
> 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.
Ah ok. That makes sense! :-). I'm still not completely sure though. ATM,
the idea was that the API would be :
public interface IContainerProvider {
void runScript();
}
which allows to do "whatever is needed" in the Ant script. Ant is still
the best in term of build process and available tasks for the job.
Actually, I still don't understand why Eclipse is not using Ant as their
underlying build tool (calling the Java API, not the scripting front
end). Had they done this, they would have immediately benefited from the
huge number of Ant tasks available, and users would have been able to
easily customize the IDE build process. Maybe the devil is in the
details... :-)
Again, the nice thing about Ant is that the scripts are already there,
we can quickly add new container support, there's no need to have a
fixed interface and the deployment strategy/setup differ from server to
server, thus we might actually be hindered by a fixed API.
In addition, the Cactus scripts automatically configure a working
container structure in an working directory. It means that the war/ear
does not get deployed in the location where the container was installed
(yuck!), but rather in a temporary working directory that can be wiped
clean after the test. Doing this from Java is a royal pain.
>
> 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.
Actually, they're not really part of Cactus. They're part of the sample
application that is packaged with the Cactus distribution to show how
Cactus tests can be automated with Ant.
They look "messy" but that's because setting up a container in your own
directory and deploying an application in it *is* messy.
BTW, this is way I'm currently spending all my energy on building Cactus
front-ends (Maven plugin, Cactus plugin, standalone cactus application):
in order to be able to "hide" the underlying mechanics and be able to
provide end to end Cactus test runs at a push of a button ! :-)
Have you tried the maven plug-in ? I love it! It can't be simpler. You
put your cactus test classes in a src directory (for ex:
src/test-cactus) and then you type:
"maven cactus:test-tomcat-4x"
and that's all. The plugin does all the work behind the scene and run
the tests. Then when you run "maven site" to generate your project web
site, the generated reports include the Cactus reports showing you the
result of the tests in a nice HTML page (you also get the results in the
console when you execute "maven cactus:test-tomcat-4x").
If you're a Cactus newbie, it takes from start to finish about 10
seconds to understand the concept and run your tests.
I would like the eclipse plugin to be the same but for development (i.e.
from inside the IDE). The easiness of use should be similar.
> And I've never been quite happy
> with the Ant support in Eclipse...
yep, but I'm not talking about using the Ant UI here. We'll call the
AntRunner programmatically. What problems do you reckon we might have?
>
> Anyway, I'll be upgrading to Eclipse 2.1 and trying to build the
> plugin... ;-)
BTW, I think it will work as well in 2.0 than in 2.1 ... (I fixed that
this week end).
Thanks. Please continue the discussion ! :-)
-Vincent
>
> 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 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!
> >
> > -Vincen
>
> --
> 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>
