Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt

[Christopher Lenz]

Vincent Massol wrote:

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();
}

[snip]

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

Okay, but that implies that the script contains the <runservertests> task to separate the phases (startup/deploy, test, shutdown), and also that the tests will get run by Ant.

If I'm understanding the situation correctly, the interface you propose would mix two basically different concerns: container interaction on the one side, and test execution on the other. Test execution, however, could simply be delegated to the existing Eclipse JUnit Plugin. In fact, the Cactus plugin would sort of 'decorate' the JUnit plugin by adding the container interaction before and after the tests.

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.

I've been looking at the Ant scripts in the sample-servlet, and they all have the same basic structure (startup, deploy, test, shutdown). It should be possible to formalize those steps in the IContainerProvider interface without the danger of having an API that hinders integration with some containers. I.e., the requirements are already well known.

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.

Yeah, that's a very valid concern. I'm not sure, but maybe the Eclipse resources API can help there. Will have to look into it.

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'll have to take another look at Maven. There's something about that tool that always tended to scare me somehow, but probably I should try getting over that ;-)

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.

Definitely.

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?

I don't know, I've rarely worked with Ant on that level. It simply looks like a lot of overhead and a potential source of problems.

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).

Hmmm, probably the .classpath file with the fixed paths to the plugins shouldn't be in CVS. I haven't gotten it to work under either 2.0 or 2.1 yet, but I'm pretty sure that's my fault :-P

--
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>