> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@;gmx.de]
> Sent: 20 October 2002 21:12
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> 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.
Actually runservertests is no longer needed as it can now be done with
Ant 1.5 (using the waitfor task, parallel and http one). But why do you
see a problem that the runservertests should be in the script? As I view
it, the cactus-ant.jar jar would be inside the Eclipse plugin as a
runtime dependency and will get added automatically to the Ant CP.
Agreed about Ant, although there is another solution: use Jelly. Jelly
supports Ant and lots of others scripting languages. Actually the Cactus
Maven plugin uses jelly scripts.
But for the sake of the discussion, let's call our interface:
public interface IContainerProvider {
void runAntScript();
}
hmm ... What it means in reality is that the core engine of the Cactus
plugin is the Ant script and the Eclipse java code is only the UI. That
would be fine to me if it works.
> 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.
Yep! That's *exactly* what we have started doing. The Cactus plugin
extends the JUnit one.
>
> > 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.
Yes, you are right, if we stay at high level tasks like
deploy/start/stop/etc. What I am concerned with is the link between the
steps which are harder to bridge if you change technology.
Actually, I agree with all that you say :-). I'm only concerned about
providing a working plugin ASAP and if the Ant integration works, I
believe it is the fastest way. I am 200% ok to start doing a proper
JSR107 interface and start afterwards. Or if you're interested you could
work on that. Again, the more help we have the more ideas we can try!
>
> > 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 ;-)
Because you loose some of the control? Yeah that's true but you win so
many existing plugins that it's a dream come true ! ;-) Ant has told us
to love our build process. Maven is telling us that the build in itself
is not really what counts but more what are the outputs of the build.
Maven is saying, leavee the nitty-gritty details of building to me, just
concentrate on what you want out of your build!
>
> > 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.
You may be right! I have worked with Ant at the Java API level for some
time but I haven't worked with it from within Eclipse. I still believe
it's worth a try, as it is easy to try:
import org.eclipse.ant.core.AntRunner?;
import org.eclipse.core.runtime.IProgressMonitor;
public class Running {
public static void main(String[] args) throws Exception {
IProgressMonitor monitor = ...
AntRunner? runner = new AntRunner?();
runner.setBuildFileLocation("c:/buildfiles/build.xml");
runner.setArguments("-Dmessage=Building -verbose");
runner.run(monitor);
}
}
>
> >>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
hummm... If possible I would really like to commit the
.classpath/.project files (I think this is the way Eclipse is doing it).
Could you tell me what errors do you get. I'm keen on making this work.
You are "importing" the project in eclipse, right?
Thanks a lot again
-Vincent
>
> --
> 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>
