You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by vm...@apache.org on 2002/10/19 15:42:21 UTC
cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
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)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 20 October 2002 22:17
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> Vincent Massol wrote:
> >>Okay, I *have* it working under 2.0 now, after removing the entries
> >
> > from
> >
> >>.classpath and invoking "Update Classpath...". Eclipse 2.1 M2 fails
> >>however... which version are you using?
> >
> >
> > Can you do a CVS diff of .classpath and post it ?
>
> Well, the problem is simple: the .classpath file contains
> <classpathentry> elements pointing to the required plugins. Although
> those paths are at least relative in terms of starting at
ECLIPSE_HOME,
> the plugin paths include the version id, so it's (for example)
> ECLIPSE_HOME/plugins/org.eclipse.core.runtime_2.1.0/runtime.jar
> which of course causes an error under Eclipse 2.0.
>
> I'm not sure what the solution is, but for now I'd just not keep it in
> CVS (similar to build.properties in the Ant world).
>
> > I'm using Eclipse 2.1 build 200210150832 but I plan to use the M2
> > tomorrow.
>
> You have been warned ;-)
>
Arg! Ok, I will renamed the .classpath as .classpath.sample for the time
being until we find a solution. The solution that I had before was to
put project dependencies but that forces you to have all the Eclipse
project in your workspace ... not better.
I'll ask on the Eclipse tools newsgroup.
Thanks
-Vincent
> --
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
>>Okay, I *have* it working under 2.0 now, after removing the entries
>
> from
>
>>.classpath and invoking "Update Classpath...". Eclipse 2.1 M2 fails
>>however... which version are you using?
>
>
> Can you do a CVS diff of .classpath and post it ?
Well, the problem is simple: the .classpath file contains
<classpathentry> elements pointing to the required plugins. Although
those paths are at least relative in terms of starting at ECLIPSE_HOME,
the plugin paths include the version id, so it's (for example)
ECLIPSE_HOME/plugins/org.eclipse.core.runtime_2.1.0/runtime.jar
which of course causes an error under Eclipse 2.0.
I'm not sure what the solution is, but for now I'd just not keep it in
CVS (similar to build.properties in the Ant world).
> I'm using Eclipse 2.1 build 200210150832 but I plan to use the M2
> tomorrow.
You have been warned ;-)
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 20 October 2002 21:53
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> Christopher Lenz wrote:
> > Vincent Massol wrote:
> >> 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
> >
>
> Okay, I *have* it working under 2.0 now, after removing the entries
from
> .classpath and invoking "Update Classpath...". Eclipse 2.1 M2 fails
> however... which version are you using?
Can you do a CVS diff of .classpath and post it ?
I'm using Eclipse 2.1 build 200210150832 but I plan to use the M2
tomorrow.
Thanks
-Vincent
>
> --
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
Christopher Lenz wrote:
> Vincent Massol wrote:
>> 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
>
Okay, I *have* it working under 2.0 now, after removing the entries from
.classpath and invoking "Update Classpath...". Eclipse 2.1 M2 fails
however... which version are you using?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 20 October 2002 23:35
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> Vincent Massol wrote:
> >>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.
>
> I'm not sure I understand... :-P
Not sure I do either ;-)
I think what I meant is that if there is an interaction (like exchanging
properties) between the different actions (start, deploy, stop, install)
it might be difficult.
But forget this comment, I think it will be ok ... :-)
>
> > 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!
>
> I've taken a brief look at JSR 88 (107 is JCACHE?)
ooops, sorry ;-)
> and I don't see how
> it fits Cactus very well... it's only about deployment AFAICT, but the
> more complex tasks Cactus has to perform are setting up (in a temp
> directory, of course) and starting/stopping the container.
Yes, you are right again :-). It only addresses a small part of what we
need in Cactus...
Christopher, you have made very good points. I would love it if you were
able to work with us on the plugin!
What do you think about implementing the interface you mentioned (with
the install()/deploy()/start() and stop()) which in turn call Ant
scriptlets. We probably still need a package() one to create the
cactified war, no?
Thanks
-Vincent
>
> --
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
>>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.
I'm not sure I understand... :-P
> 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!
I've taken a brief look at JSR 88 (107 is JCACHE?) and I don't see how
it fits Cactus very well... it's only about deployment AFAICT, but the
more complex tasks Cactus has to perform are setting up (in a temp
directory, of course) and starting/stopping the container.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 20 October 2002 22:58
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
>
> Vincent Massol wrote:
> > 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.
>
> Okay, for getting the plugin off the ground, I'd consider that a good
> enough approach. But then, the plugin shouldn't have an external API,
as
> there'd be nothing to extend.
>
> >>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.
>
> That's the one point where I don't see the Ant approach working. Using
> Ant, you'd be triggering test execution through Ant's TestRunner.
> Instead, the TestRunner/Listeners/whatever set up by the Eclipse JUnit
> plugin should be used. But maybe I'm being dumb ;-)
As you said there's 2 parts in running cactus tests:
1/ prepare the server side
2/ kick off the test by running a JUnit Test Runner
1/ would be done by Ant and 2/ by the JUnit plugin.
>
> In addition, the Eclipse JUnit plugin is not (yet) designed for being
> extended/decorated. Every class in the plugin is under
> org.eclipse.jdt.internal, meaning it's not an API that should be
relied
> upon by third parties. Maybe the possibility of decorating/extending
the
> Eclipse JUnit plugin should be discussed with the corresponding
Eclipse
> team?
A very good point! You're quite right. I have been discussing with Erich
Gamma over the week end on the eclipse tools newsgroup and we have
agreed that we would send him the list of methods that we consider
should be in a JUnit plugin API.
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> 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.
Okay, for getting the plugin off the ground, I'd consider that a good
enough approach. But then, the plugin shouldn't have an external API, as
there'd be nothing to extend.
>>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.
That's the one point where I don't see the Ant approach working. Using
Ant, you'd be triggering test execution through Ant's TestRunner.
Instead, the TestRunner/Listeners/whatever set up by the Eclipse JUnit
plugin should be used. But maybe I'm being dumb ;-)
In addition, the Eclipse JUnit plugin is not (yet) designed for being
extended/decorated. Every class in the plugin is under
org.eclipse.jdt.internal, meaning it's not an API that should be relied
upon by third parties. Maybe the possibility of decorating/extending the
Eclipse JUnit plugin should be discussed with the corresponding Eclipse
team?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----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-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 20 October 2002 17:56
> To: cactus-dev@jakarta.apache.org
> 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-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
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.
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 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Vincent Massol <vm...@octo.com>.
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
>
> vmassol@apache.org 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-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Milestone 3 almost reached
Posted by Vincent Massol <vm...@octo.com>.
Cool! Thanks a lot Julien. I'm really eager to test this! Looks way
cool. Will get back to you in the coming days.
Thanks
-Vincent
> -----Original Message-----
> From: Julien Ruaux [mailto:jruaux@octo.com]
> Sent: 29 October 2002 17:42
> To: 'Cactus Developers List'
> Subject: Milestone 3 almost reached
>
> Hi Chris,
>
> I have just committed changes to the Eclipse-Plugin. It is now using a
> generic ant provider, and I have added some preferences to the Cactus
> preference page.
> If you want to check it out and tell me what you think I would be
> pleased.
>
> Julien
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Milestone 3 almost reached
Posted by Julien Ruaux <jr...@octo.com>.
Hi Chris,
I have just committed changes to the Eclipse-Plugin. It is now using a
generic ant provider, and I have added some preferences to the Cactus
preference page.
If you want to check it out and tell me what you think I would be
pleased.
Julien
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt
Posted by Christopher Lenz <cm...@gmx.de>.
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 ;-)
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?
vmassol@apache.org 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>