You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/05/23 23:12:18 UTC
[Cactus plugin] Full new rewrite
Hi,
I have just committed a full rewrite of the Maven Cactus plugin. As it
is a rewrite, I have increased the version to 3.0 (it was 2.1-SNAPSHOT
before). Note that the 3.0 version is still in development and is not
released yet. I'm waiting for feedback before releasing it.
The new version of the Cactus plugin now relies on the newest Cactus/Ant
integration which has completely changed since version 2.0 of the Maven
plugin. Thanks to the new Cactus/Ant, some features have also been
added. The plugin now uses the new <cactifywar> and <cactus> Ant tasks
(see http://jakarta.apache.org/cactus/integration/ant/index.html for
more details).
Note that version 2.1-SNAPSHOT will never get released as 1/ a bug ad
been introduced and 2/ the direction is to use the Cactus/Ant
integration which has been changed in Cactus CVS.
Please give it a try and report any issue on the Maven mailing
lists/JIRA. You can find a read-made test application in
http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
if you wish.
Thank you
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Matt Johnson <jo...@whitesmiths.com.au>.
I don't rely on the jmx console at all - I use the RMIAdaptor. You can
easily find out what's running via listDeployed in
jboss.system:service=MainDeployer. This is a lot more reliable than
looking in the "deploy" dir.
I would only recommend using this in development situations - in
Production leaving the RMIAdaptor running is a security risk.
The RMIAdaptor responds quickly even if the server is under load.
Matt
Florin Vancea wrote:
>The HTML adaptor waits indeed for deployment completion. That makes it one
>of the choices.
>
>What do you think about the "copy-and-JMX" approach (as opposed to
>"build-and-JMX-in-place")? No auto-deploy involved. You can still
>clean-build (yes, maybe yo won't be able to copy, but then usually there's a
>depper issue).
>
>I don't like having modules deployed outside the deploy dir, because it gets
>difficult to answer comfortably to the question "What's running on this
>instance?". The HTTP adapter is usable, but not that usable...
>
>----- Original Message -----
>From: "Matt Johnson" <jo...@whitesmiths.com.au>
>To: "Maven Developers List" <de...@maven.apache.org>
>Sent: Monday, May 26, 2003 4:00 AM
>Subject: Re: [Cactus plugin] Full new rewrite
>
>
>
>
>>If you use the org.jboss.ant.JMX Ant task, or even the RMIAdaptor
>>directly in some other way, then deploy calls block until the component
>>has been deployed (or fails to deploy :-) ).
>>
>>I would imagine (although untested) that this would also be the case
>>with the HTMLAdaptor.
>>
>>Basically, using JMX on in-place webapps and jars, I've had fewer
>>problems with hot deployment than using the build-and-copy process. The
>>one disadvantage is that jars in the lib directory of a webapp are
>>sometimes (on Win2k at least) locked by Jetty, and so may not be removed
>>until JBoss has been shut down. During normal development cycles, this
>>is not much of an issue, but it does mean you may need to shut down
>>jboss to do a clean build.
>>
>>
>>Matt
>>
>>Florin Vancea wrote:
>>
>>
>>
>>>Hello Vincent, hello all.
>>>
>>>This _is_ indeed a rework (as you promised not so long ago).
>>>
>>>Probably it works as intended, but I would have a few comments. In order
>>>
>>>
>to
>
>
>>>be understood, I will have to start with my history with 2.0.
>>>
>>>I am using JBoss 3.x as target container in development cycle.
>>>As soon as the ant-integration module was used in Cactus plugin I noticed
>>>that deployment of artifact (cactified WAR) was not handled quite
>>>
>>>
>properly
>
>
>>>in my particular case. I was (and am) running jboss permanently and take
>>>advantage of its hot-deploy feature. Therefore, when trying Cactus within
>>>Maven I was naturally expecting to use the same (already started) JBoss.
>>>As I checked, the test runner task was prepared to "understand" this, as
>>>
>>>
>it
>
>
>>>does not blindly try to start and stop the container. Cool.
>>>However, it also does not wait for hot-deployment to completely happen.
>>>
>>>
>If I
>
>
>>>start the container from scratch, this is not an issue, but if the
>>>
>>>
>container
>
>
>>>is already started and I do a WAR copy into confname/deploy dir, then the
>>>tests are run sometimes _before_ the deployment (using the old WAR) or
>>>_during_ the deployment. In both cases horrible error logs occur and of
>>>course the build fails.
>>>
>>>Then I decided that if it's not implemented than probably I'm the one
>>>
>>>
>being
>
>
>>>weird and I did my own hacking: Whipped up my own Ant task doing JMX
>>>"surveillance" to block the build until proper undeploy/deploy took
>>>
>>>
>place.
>
>
>>>Since I did not want to hack two projects if I could help it, I hacked
>>>
>>>
>only
>
>
>>>Maven's plugin to replace build-tests-jboss3x.xml from integration jar
>>>
>>>
>"on
>
>
>>>the fly" with my own version that did the JMX waiting.
>>>
>>>Now 3.0 kicks in, and I have to say it looks elegant (no more weird jars
>>>unpacked locally). But this is bad news for me, since the new kit does
>>>
>>>
>not
>
>
>>>work as I'd expect when the container is already started.
>>>I took the time to dig in Cactus sources from CVS and it appears
>>>
>>>
>(confirmed
>
>
>>>by my tests) that:
>>>
>>>"If the container is already started, no deployment takes place (method
>>>JBoss3xContainer.prepare() is never called ) and tests are run directly."
>>>And fail or run whatever WAR they find in there, not necessarily the
>>>
>>>
>fresh
>
>
>>>one.
>>>
>>>It is reasonable to suppose that this is intended behavior and that one
>>>would expect the caller to make its own deployment beforehand. I can live
>>>with that. However, I would like to know what's the projected course of
>>>action:
>>>
>>>1. Is this the planned way to go? Then Maven plugin (at least my version
>>>
>>>
>but
>
>
>>>maybe I'm not the only one) should take care of deploying the cactified
>>>
>>>
>WAR.
>
>
>>>At the very least, there should be a warning somewhere in the generated
>>>
>>>
>docs
>
>
>>>that one should do it via <preGoal name="cactus:test" > in its maven.xml.
>>>
>>>
>I
>
>
>>>could help with that if needed.
>>>
>>>or
>>>
>>>2. This is a slip in cactus-ant and it will get corrected, such that when
>>>the container is already started the deployment still takes place (but
>>>please, do not forget to JMX-wait for complete deployment or deploy via
>>>
>>>
>JMX
>
>
>>>"in place" the cactified WAR). Then the plugin is fine as-is, but changes
>>>are strongly required in cactus-ant to support the "developer mode" usage
>>>pattern. If this is the case, please-please do not forget the waiting
>>>
>>>
>stuff,
>
>
>>>otherwise the whole package will get unusable with hot-deploy JBoss, not
>>>even in "mode 1" above.
>>>
>>>Thanks for reading this far; I'm expecting your opinions.
>>>
>>>Florin
>>>
>>>----- Original Message -----
>>>From: "Vincent Massol" <vm...@pivolis.com>
>>>To: <de...@maven.apache.org>
>>>Cc: <us...@maven.apache.org>
>>>Sent: Saturday, May 24, 2003 12:12 AM
>>>Subject: [Cactus plugin] Full new rewrite
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I have just committed a full rewrite of the Maven Cactus plugin. As it
>>>>is a rewrite, I have increased the version to 3.0 (it was 2.1-SNAPSHOT
>>>>before). Note that the 3.0 version is still in development and is not
>>>>released yet. I'm waiting for feedback before releasing it.
>>>>
>>>>The new version of the Cactus plugin now relies on the newest Cactus/Ant
>>>>integration which has completely changed since version 2.0 of the Maven
>>>>plugin. Thanks to the new Cactus/Ant, some features have also been
>>>>added. The plugin now uses the new <cactifywar> and <cactus> Ant tasks
>>>>(see http://jakarta.apache.org/cactus/integration/ant/index.html for
>>>>more details).
>>>>
>>>>Note that version 2.1-SNAPSHOT will never get released as 1/ a bug ad
>>>>been introduced and 2/ the direction is to use the Cactus/Ant
>>>>integration which has been changed in Cactus CVS.
>>>>
>>>>Please give it a try and report any issue on the Maven mailing
>>>>lists/JIRA. You can find a read-made test application in
>>>>http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
>>>>if you wish.
>>>>
>>>>Thank you
>>>>-Vincent
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Florin Vancea <fv...@maxiq.ro>.
The HTML adaptor waits indeed for deployment completion. That makes it one
of the choices.
What do you think about the "copy-and-JMX" approach (as opposed to
"build-and-JMX-in-place")? No auto-deploy involved. You can still
clean-build (yes, maybe yo won't be able to copy, but then usually there's a
depper issue).
I don't like having modules deployed outside the deploy dir, because it gets
difficult to answer comfortably to the question "What's running on this
instance?". The HTTP adapter is usable, but not that usable...
----- Original Message -----
From: "Matt Johnson" <jo...@whitesmiths.com.au>
To: "Maven Developers List" <de...@maven.apache.org>
Sent: Monday, May 26, 2003 4:00 AM
Subject: Re: [Cactus plugin] Full new rewrite
> If you use the org.jboss.ant.JMX Ant task, or even the RMIAdaptor
> directly in some other way, then deploy calls block until the component
> has been deployed (or fails to deploy :-) ).
>
> I would imagine (although untested) that this would also be the case
> with the HTMLAdaptor.
>
> Basically, using JMX on in-place webapps and jars, I've had fewer
> problems with hot deployment than using the build-and-copy process. The
> one disadvantage is that jars in the lib directory of a webapp are
> sometimes (on Win2k at least) locked by Jetty, and so may not be removed
> until JBoss has been shut down. During normal development cycles, this
> is not much of an issue, but it does mean you may need to shut down
> jboss to do a clean build.
>
>
> Matt
>
> Florin Vancea wrote:
>
> >Hello Vincent, hello all.
> >
> >This _is_ indeed a rework (as you promised not so long ago).
> >
> >Probably it works as intended, but I would have a few comments. In order
to
> >be understood, I will have to start with my history with 2.0.
> >
> >I am using JBoss 3.x as target container in development cycle.
> >As soon as the ant-integration module was used in Cactus plugin I noticed
> >that deployment of artifact (cactified WAR) was not handled quite
properly
> >in my particular case. I was (and am) running jboss permanently and take
> >advantage of its hot-deploy feature. Therefore, when trying Cactus within
> >Maven I was naturally expecting to use the same (already started) JBoss.
> >As I checked, the test runner task was prepared to "understand" this, as
it
> >does not blindly try to start and stop the container. Cool.
> >However, it also does not wait for hot-deployment to completely happen.
If I
> >start the container from scratch, this is not an issue, but if the
container
> >is already started and I do a WAR copy into confname/deploy dir, then the
> >tests are run sometimes _before_ the deployment (using the old WAR) or
> >_during_ the deployment. In both cases horrible error logs occur and of
> >course the build fails.
> >
> >Then I decided that if it's not implemented than probably I'm the one
being
> >weird and I did my own hacking: Whipped up my own Ant task doing JMX
> >"surveillance" to block the build until proper undeploy/deploy took
place.
> >Since I did not want to hack two projects if I could help it, I hacked
only
> >Maven's plugin to replace build-tests-jboss3x.xml from integration jar
"on
> >the fly" with my own version that did the JMX waiting.
> >
> >Now 3.0 kicks in, and I have to say it looks elegant (no more weird jars
> >unpacked locally). But this is bad news for me, since the new kit does
not
> >work as I'd expect when the container is already started.
> >I took the time to dig in Cactus sources from CVS and it appears
(confirmed
> >by my tests) that:
> >
> >"If the container is already started, no deployment takes place (method
> >JBoss3xContainer.prepare() is never called ) and tests are run directly."
> >And fail or run whatever WAR they find in there, not necessarily the
fresh
> >one.
> >
> >It is reasonable to suppose that this is intended behavior and that one
> >would expect the caller to make its own deployment beforehand. I can live
> >with that. However, I would like to know what's the projected course of
> >action:
> >
> >1. Is this the planned way to go? Then Maven plugin (at least my version
but
> >maybe I'm not the only one) should take care of deploying the cactified
WAR.
> >At the very least, there should be a warning somewhere in the generated
docs
> >that one should do it via <preGoal name="cactus:test" > in its maven.xml.
I
> >could help with that if needed.
> >
> >or
> >
> >2. This is a slip in cactus-ant and it will get corrected, such that when
> >the container is already started the deployment still takes place (but
> >please, do not forget to JMX-wait for complete deployment or deploy via
JMX
> >"in place" the cactified WAR). Then the plugin is fine as-is, but changes
> >are strongly required in cactus-ant to support the "developer mode" usage
> >pattern. If this is the case, please-please do not forget the waiting
stuff,
> >otherwise the whole package will get unusable with hot-deploy JBoss, not
> >even in "mode 1" above.
> >
> >Thanks for reading this far; I'm expecting your opinions.
> >
> >Florin
> >
> >----- Original Message -----
> >From: "Vincent Massol" <vm...@pivolis.com>
> >To: <de...@maven.apache.org>
> >Cc: <us...@maven.apache.org>
> >Sent: Saturday, May 24, 2003 12:12 AM
> >Subject: [Cactus plugin] Full new rewrite
> >
> >
> >
> >
> >>Hi,
> >>
> >>I have just committed a full rewrite of the Maven Cactus plugin. As it
> >>is a rewrite, I have increased the version to 3.0 (it was 2.1-SNAPSHOT
> >>before). Note that the 3.0 version is still in development and is not
> >>released yet. I'm waiting for feedback before releasing it.
> >>
> >>The new version of the Cactus plugin now relies on the newest Cactus/Ant
> >>integration which has completely changed since version 2.0 of the Maven
> >>plugin. Thanks to the new Cactus/Ant, some features have also been
> >>added. The plugin now uses the new <cactifywar> and <cactus> Ant tasks
> >>(see http://jakarta.apache.org/cactus/integration/ant/index.html for
> >>more details).
> >>
> >>Note that version 2.1-SNAPSHOT will never get released as 1/ a bug ad
> >>been introduced and 2/ the direction is to use the Cactus/Ant
> >>integration which has been changed in Cactus CVS.
> >>
> >>Please give it a try and report any issue on the Maven mailing
> >>lists/JIRA. You can find a read-made test application in
> >>http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
> >>if you wish.
> >>
> >>Thank you
> >>-Vincent
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Matt Johnson <jo...@whitesmiths.com.au>.
If you use the org.jboss.ant.JMX Ant task, or even the RMIAdaptor
directly in some other way, then deploy calls block until the component
has been deployed (or fails to deploy :-) ).
I would imagine (although untested) that this would also be the case
with the HTMLAdaptor.
Basically, using JMX on in-place webapps and jars, I've had fewer
problems with hot deployment than using the build-and-copy process. The
one disadvantage is that jars in the lib directory of a webapp are
sometimes (on Win2k at least) locked by Jetty, and so may not be removed
until JBoss has been shut down. During normal development cycles, this
is not much of an issue, but it does mean you may need to shut down
jboss to do a clean build.
Matt
Florin Vancea wrote:
>Hello Vincent, hello all.
>
>This _is_ indeed a rework (as you promised not so long ago).
>
>Probably it works as intended, but I would have a few comments. In order to
>be understood, I will have to start with my history with 2.0.
>
>I am using JBoss 3.x as target container in development cycle.
>As soon as the ant-integration module was used in Cactus plugin I noticed
>that deployment of artifact (cactified WAR) was not handled quite properly
>in my particular case. I was (and am) running jboss permanently and take
>advantage of its hot-deploy feature. Therefore, when trying Cactus within
>Maven I was naturally expecting to use the same (already started) JBoss.
>As I checked, the test runner task was prepared to "understand" this, as it
>does not blindly try to start and stop the container. Cool.
>However, it also does not wait for hot-deployment to completely happen. If I
>start the container from scratch, this is not an issue, but if the container
>is already started and I do a WAR copy into confname/deploy dir, then the
>tests are run sometimes _before_ the deployment (using the old WAR) or
>_during_ the deployment. In both cases horrible error logs occur and of
>course the build fails.
>
>Then I decided that if it's not implemented than probably I'm the one being
>weird and I did my own hacking: Whipped up my own Ant task doing JMX
>"surveillance" to block the build until proper undeploy/deploy took place.
>Since I did not want to hack two projects if I could help it, I hacked only
>Maven's plugin to replace build-tests-jboss3x.xml from integration jar "on
>the fly" with my own version that did the JMX waiting.
>
>Now 3.0 kicks in, and I have to say it looks elegant (no more weird jars
>unpacked locally). But this is bad news for me, since the new kit does not
>work as I'd expect when the container is already started.
>I took the time to dig in Cactus sources from CVS and it appears (confirmed
>by my tests) that:
>
>"If the container is already started, no deployment takes place (method
>JBoss3xContainer.prepare() is never called ) and tests are run directly."
>And fail or run whatever WAR they find in there, not necessarily the fresh
>one.
>
>It is reasonable to suppose that this is intended behavior and that one
>would expect the caller to make its own deployment beforehand. I can live
>with that. However, I would like to know what's the projected course of
>action:
>
>1. Is this the planned way to go? Then Maven plugin (at least my version but
>maybe I'm not the only one) should take care of deploying the cactified WAR.
>At the very least, there should be a warning somewhere in the generated docs
>that one should do it via <preGoal name="cactus:test" > in its maven.xml. I
>could help with that if needed.
>
>or
>
>2. This is a slip in cactus-ant and it will get corrected, such that when
>the container is already started the deployment still takes place (but
>please, do not forget to JMX-wait for complete deployment or deploy via JMX
>"in place" the cactified WAR). Then the plugin is fine as-is, but changes
>are strongly required in cactus-ant to support the "developer mode" usage
>pattern. If this is the case, please-please do not forget the waiting stuff,
>otherwise the whole package will get unusable with hot-deploy JBoss, not
>even in "mode 1" above.
>
>Thanks for reading this far; I'm expecting your opinions.
>
>Florin
>
>----- Original Message -----
>From: "Vincent Massol" <vm...@pivolis.com>
>To: <de...@maven.apache.org>
>Cc: <us...@maven.apache.org>
>Sent: Saturday, May 24, 2003 12:12 AM
>Subject: [Cactus plugin] Full new rewrite
>
>
>
>
>>Hi,
>>
>>I have just committed a full rewrite of the Maven Cactus plugin. As it
>>is a rewrite, I have increased the version to 3.0 (it was 2.1-SNAPSHOT
>>before). Note that the 3.0 version is still in development and is not
>>released yet. I'm waiting for feedback before releasing it.
>>
>>The new version of the Cactus plugin now relies on the newest Cactus/Ant
>>integration which has completely changed since version 2.0 of the Maven
>>plugin. Thanks to the new Cactus/Ant, some features have also been
>>added. The plugin now uses the new <cactifywar> and <cactus> Ant tasks
>>(see http://jakarta.apache.org/cactus/integration/ant/index.html for
>>more details).
>>
>>Note that version 2.1-SNAPSHOT will never get released as 1/ a bug ad
>>been introduced and 2/ the direction is to use the Cactus/Ant
>>integration which has been changed in Cactus CVS.
>>
>>Please give it a try and report any issue on the Maven mailing
>>lists/JIRA. You can find a read-made test application in
>>http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
>>if you wish.
>>
>>Thank you
>>-Vincent
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Florin Vancea <fv...@maxiq.ro>.
BackNote :) : I'm only hooked up to maven-dev list and I'd really-really not
link into cactus-dev unless I really have to. There are already too many
lists I'm trying to track and once I "adopt" one it's hard for me to let go
:)
Therefore, whoever is participating in this thread from cactus-dev,
pretty-please cc to me, too, especially if this issue moves out of
maven-dev.
This cleared, see below.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Florin Vancea'" <fv...@maxiq.ro>
Cc: <de...@maven.apache.org>; "'Cactus Developers List'"
<ca...@jakarta.apache.org>
Sent: Saturday, May 24, 2003 2:47 PM
Subject: RE: [Cactus plugin] Full new rewrite
> Note: I'm cc-ing the cactus dev list as it is of interest to both lists
> (probably even more to the cactus one and conversation should probably
> be moved to there).
>
> See below.
>
[snip]
>
> Ah yes. This is definitely a use case I have not tested: hot
> redeployment... (I always start the container from scratch). Your help
> is very valuable!
>
Thanks.
> >
> > Then I decided that if it's not implemented than probably I'm the one
> > being
> > weird
>
> absolutely not. It's simply that we haven't really looked at hot
> deployment so far. With your help, we can hopefully fix it quickly.
Let's try then.
>
[snip]
>
> No, that's not the intention I believe. Our goal is to make it the
> simplest possible for end users. That said, there are 2 main front-ends
> (aka integration) for Cactus for automated builds:
>
> 1/ The Ant integration: this is for advanced users who wish to
> completely control their builds. There is a <generic> container tag that
> can be used in inside the <cactus> task to control everything.
Now that you mentioned it, I took a peek into GenericContainer. It seems to
me it has no "deploy" task. I believe some containers have to be started for
deploy to take place (i.e. just copying the artifact somewhere is not
enough). Shouldn't there be also a "deploy" hook?
Actually the processing as I see it (based on my experience with JBoss) is
something like:
1. Start if not already started. (this may also prepare some config-info if
needed)
2. Deploy cactified WAR. Make sure deployment is over. (this step may need
some additional info if we were not the creators of the current config - we
were not the ones who started in step 1.)
3. Run tests (this is the job of some higher entity, like the <cactus> tag)
4. Shutdown if we started it. (maybe here we should cleanup/undeploy, at
least when tests succeeded).
>
> 2/ The Maven integration is for end users who want to use Cactus in the
> easiest possible manner. It currently supports the most basic uses cases
> and my goal is to improve it to support more and more scenarios as I get
> feedback from its users, such as what you are reporting.
For continuous integration purposes, the start/test/stop approach is best,
since it goes cleaner. However for development (even if it's just developing
tests) starting/stopping something like JBoss, with a full-feature setup,
it's a huge hit.
>
> >
> > or
> >
> > 2. This is a slip in cactus-ant and it will get corrected, such that
> when
> > the container is already started the deployment still takes place (but
> > please, do not forget to JMX-wait for complete deployment or deploy
> via
> > JMX
> > "in place" the cactified WAR). Then the plugin is fine as-is, but
> changes
> > are strongly required in cactus-ant to support the "developer mode"
> usage
> > pattern. If this is the case, please-please do not forget the waiting
> > stuff,
> > otherwise the whole package will get unusable with hot-deploy JBoss,
> not
> > even in "mode 1" above.
>
> +1. Thanks for the suggestion. Could you send us your JMX-wait
> implementation so that we can use it?
Now that'll take some time. It's a messy one. If still wanted after reading
the following, I'll do it. (don't forget the licensing issues for the client
part of JBoss, too).
I wanted to clean it up to the point it is postable some time in the past,
for maven-jboss-plugin, but James was quicker to provide a much simpler
approach. His idea is usable here, too. The only drawback is that it's
applicable for deployment "in place", i.e. it deploys the very WAR locally
produced (be it file or dir structure). After testing it should be mandatory
to undeploy it automatically, otherwise executing a subsequent "clean"
target will/might blow the running JBoss.
Another possibility would be after starting to go like:
1. delete the WAR from /deploy/ dir
2. wait until a HTTP request for that Cactus context fails 404
3. copy the new WAR
4. wait until a "dummy" request for that Cactus context succeeds (NOT a test
request)
5. start testing
This is tricky, due to the thread pooling that goes underneath in the
servlet container. Lots of odd errors (actually expectable due to the
approach) will pop in the debug/console and might even cause more unexpected
results.
Yet another way would be to "reserve" a dir sibling to JBoss's canonical
/deploy. Let's call it /cactusdeploy. it would go like this:
1. make sure cactudeploy exists (beware: shouldn't be
autodeploy-configured).
2-pre. trigger undeployment of any same-named existing WAR there using HTTP
adapter (James-way)
2. copy the WAR there
3. trigger deployment using HTTP adapter (James-way)
4. run the tests
5. undeploy using HTTP adapter (if desired, for cleaning-up)
If something goes bad, the leftover is in jboss dir structure and not
affected by clean, and furthermore not loaded automatically on next restart
(i.e. no risk for bloating or conflicts).
The disadvantage is that one additional copy is required.
Yet-yet another way: As I said the previous time, there is an Ant task in
JBoss distribution itself. However, AFAIK, even the 3.2 series do not have
the final touch on it, let alone 3.0x ones.
>
> >
> > Thanks for reading this far; I'm expecting your opinions.
> >
>
> Thanks for your feedback.
> -Vincent
>
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Florin Vancea <fv...@maxiq.ro>.
BackNote :) : I'm only hooked up to maven-dev list and I'd really-really not
link into cactus-dev unless I really have to. There are already too many
lists I'm trying to track and once I "adopt" one it's hard for me to let go
:)
Therefore, whoever is participating in this thread from cactus-dev,
pretty-please cc to me, too, especially if this issue moves out of
maven-dev.
This cleared, see below.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Florin Vancea'" <fv...@maxiq.ro>
Cc: <de...@maven.apache.org>; "'Cactus Developers List'"
<ca...@jakarta.apache.org>
Sent: Saturday, May 24, 2003 2:47 PM
Subject: RE: [Cactus plugin] Full new rewrite
> Note: I'm cc-ing the cactus dev list as it is of interest to both lists
> (probably even more to the cactus one and conversation should probably
> be moved to there).
>
> See below.
>
[snip]
>
> Ah yes. This is definitely a use case I have not tested: hot
> redeployment... (I always start the container from scratch). Your help
> is very valuable!
>
Thanks.
> >
> > Then I decided that if it's not implemented than probably I'm the one
> > being
> > weird
>
> absolutely not. It's simply that we haven't really looked at hot
> deployment so far. With your help, we can hopefully fix it quickly.
Let's try then.
>
[snip]
>
> No, that's not the intention I believe. Our goal is to make it the
> simplest possible for end users. That said, there are 2 main front-ends
> (aka integration) for Cactus for automated builds:
>
> 1/ The Ant integration: this is for advanced users who wish to
> completely control their builds. There is a <generic> container tag that
> can be used in inside the <cactus> task to control everything.
Now that you mentioned it, I took a peek into GenericContainer. It seems to
me it has no "deploy" task. I believe some containers have to be started for
deploy to take place (i.e. just copying the artifact somewhere is not
enough). Shouldn't there be also a "deploy" hook?
Actually the processing as I see it (based on my experience with JBoss) is
something like:
1. Start if not already started. (this may also prepare some config-info if
needed)
2. Deploy cactified WAR. Make sure deployment is over. (this step may need
some additional info if we were not the creators of the current config - we
were not the ones who started in step 1.)
3. Run tests (this is the job of some higher entity, like the <cactus> tag)
4. Shutdown if we started it. (maybe here we should cleanup/undeploy, at
least when tests succeeded).
>
> 2/ The Maven integration is for end users who want to use Cactus in the
> easiest possible manner. It currently supports the most basic uses cases
> and my goal is to improve it to support more and more scenarios as I get
> feedback from its users, such as what you are reporting.
For continuous integration purposes, the start/test/stop approach is best,
since it goes cleaner. However for development (even if it's just developing
tests) starting/stopping something like JBoss, with a full-feature setup,
it's a huge hit.
>
> >
> > or
> >
> > 2. This is a slip in cactus-ant and it will get corrected, such that
> when
> > the container is already started the deployment still takes place (but
> > please, do not forget to JMX-wait for complete deployment or deploy
> via
> > JMX
> > "in place" the cactified WAR). Then the plugin is fine as-is, but
> changes
> > are strongly required in cactus-ant to support the "developer mode"
> usage
> > pattern. If this is the case, please-please do not forget the waiting
> > stuff,
> > otherwise the whole package will get unusable with hot-deploy JBoss,
> not
> > even in "mode 1" above.
>
> +1. Thanks for the suggestion. Could you send us your JMX-wait
> implementation so that we can use it?
Now that'll take some time. It's a messy one. If still wanted after reading
the following, I'll do it. (don't forget the licensing issues for the client
part of JBoss, too).
I wanted to clean it up to the point it is postable some time in the past,
for maven-jboss-plugin, but James was quicker to provide a much simpler
approach. His idea is usable here, too. The only drawback is that it's
applicable for deployment "in place", i.e. it deploys the very WAR locally
produced (be it file or dir structure). After testing it should be mandatory
to undeploy it automatically, otherwise executing a subsequent "clean"
target will/might blow the running JBoss.
Another possibility would be after starting to go like:
1. delete the WAR from /deploy/ dir
2. wait until a HTTP request for that Cactus context fails 404
3. copy the new WAR
4. wait until a "dummy" request for that Cactus context succeeds (NOT a test
request)
5. start testing
This is tricky, due to the thread pooling that goes underneath in the
servlet container. Lots of odd errors (actually expectable due to the
approach) will pop in the debug/console and might even cause more unexpected
results.
Yet another way would be to "reserve" a dir sibling to JBoss's canonical
/deploy. Let's call it /cactusdeploy. it would go like this:
1. make sure cactudeploy exists (beware: shouldn't be
autodeploy-configured).
2-pre. trigger undeployment of any same-named existing WAR there using HTTP
adapter (James-way)
2. copy the WAR there
3. trigger deployment using HTTP adapter (James-way)
4. run the tests
5. undeploy using HTTP adapter (if desired, for cleaning-up)
If something goes bad, the leftover is in jboss dir structure and not
affected by clean, and furthermore not loaded automatically on next restart
(i.e. no risk for bloating or conflicts).
The disadvantage is that one additional copy is required.
Yet-yet another way: As I said the previous time, there is an Ant task in
JBoss distribution itself. However, AFAIK, even the 3.2 series do not have
the final touch on it, let alone 3.0x ones.
>
> >
> > Thanks for reading this far; I'm expecting your opinions.
> >
>
> Thanks for your feedback.
> -Vincent
>
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [Cactus plugin] Full new rewrite
Posted by Vincent Massol <vm...@pivolis.com>.
Note: I'm cc-ing the cactus dev list as it is of interest to both lists
(probably even more to the cactus one and conversation should probably
be moved to there).
See below.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 24 May 2003 12:12
> To: dev@maven.apache.org
> Cc: Vincent Massol
> Subject: Re: [Cactus plugin] Full new rewrite
>
> Hello Vincent, hello all.
>
> This _is_ indeed a rework (as you promised not so long ago).
>
> Probably it works as intended, but I would have a few comments. In
order
> to
> be understood, I will have to start with my history with 2.0.
It has not yet been fully tested yet (I had tried it on Resin 2.x and
Tomcat 4.x). I have just fixed a bug to make it work with JBoss 3.2.1.
>
> I am using JBoss 3.x as target container in development cycle.
> As soon as the ant-integration module was used in Cactus plugin I
noticed
> that deployment of artifact (cactified WAR) was not handled quite
properly
> in my particular case. I was (and am) running jboss permanently and
take
> advantage of its hot-deploy feature. Therefore, when trying Cactus
within
> Maven I was naturally expecting to use the same (already started)
JBoss.
> As I checked, the test runner task was prepared to "understand" this,
as
> it
> does not blindly try to start and stop the container. Cool.
> However, it also does not wait for hot-deployment to completely
happen. If
> I
> start the container from scratch, this is not an issue, but if the
> container
> is already started and I do a WAR copy into confname/deploy dir, then
the
> tests are run sometimes _before_ the deployment (using the old WAR) or
> _during_ the deployment. In both cases horrible error logs occur and
of
> course the build fails.
Ah yes. This is definitely a use case I have not tested: hot
redeployment... (I always start the container from scratch). Your help
is very valuable!
>
> Then I decided that if it's not implemented than probably I'm the one
> being
> weird
absolutely not. It's simply that we haven't really looked at hot
deployment so far. With your help, we can hopefully fix it quickly.
> and I did my own hacking: Whipped up my own Ant task doing JMX
> "surveillance" to block the build until proper undeploy/deploy took
place.
> Since I did not want to hack two projects if I could help it, I hacked
> only
> Maven's plugin to replace build-tests-jboss3x.xml from integration jar
"on
> the fly" with my own version that did the JMX waiting.
>
> Now 3.0 kicks in, and I have to say it looks elegant (no more weird
jars
> unpacked locally). But this is bad news for me, since the new kit does
not
> work as I'd expect when the container is already started.
> I took the time to dig in Cactus sources from CVS and it appears
> (confirmed
> by my tests) that:
>
> "If the container is already started, no deployment takes place
(method
> JBoss3xContainer.prepare() is never called ) and tests are run
directly."
> And fail or run whatever WAR they find in there, not necessarily the
fresh
> one.
>
> It is reasonable to suppose that this is intended behavior and that
one
> would expect the caller to make its own deployment beforehand. I can
live
> with that. However, I would like to know what's the projected course
of
> action:
>
> 1. Is this the planned way to go? Then Maven plugin (at least my
version
> but
> maybe I'm not the only one) should take care of deploying the
cactified
> WAR.
> At the very least, there should be a warning somewhere in the
generated
> docs
> that one should do it via <preGoal name="cactus:test" > in its
maven.xml.
> I
> could help with that if needed.
No, that's not the intention I believe. Our goal is to make it the
simplest possible for end users. That said, there are 2 main front-ends
(aka integration) for Cactus for automated builds:
1/ The Ant integration: this is for advanced users who wish to
completely control their builds. There is a <generic> container tag that
can be used in inside the <cactus> task to control everything.
2/ The Maven integration is for end users who want to use Cactus in the
easiest possible manner. It currently supports the most basic uses cases
and my goal is to improve it to support more and more scenarios as I get
feedback from its users, such as what you are reporting.
>
> or
>
> 2. This is a slip in cactus-ant and it will get corrected, such that
when
> the container is already started the deployment still takes place (but
> please, do not forget to JMX-wait for complete deployment or deploy
via
> JMX
> "in place" the cactified WAR). Then the plugin is fine as-is, but
changes
> are strongly required in cactus-ant to support the "developer mode"
usage
> pattern. If this is the case, please-please do not forget the waiting
> stuff,
> otherwise the whole package will get unusable with hot-deploy JBoss,
not
> even in "mode 1" above.
+1. Thanks for the suggestion. Could you send us your JMX-wait
implementation so that we can use it?
>
> Thanks for reading this far; I'm expecting your opinions.
>
Thanks for your feedback.
-Vincent
> Florin
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: <de...@maven.apache.org>
> Cc: <us...@maven.apache.org>
> Sent: Saturday, May 24, 2003 12:12 AM
> Subject: [Cactus plugin] Full new rewrite
>
>
> > Hi,
> >
> > I have just committed a full rewrite of the Maven Cactus plugin. As
it
> > is a rewrite, I have increased the version to 3.0 (it was
2.1-SNAPSHOT
> > before). Note that the 3.0 version is still in development and is
not
> > released yet. I'm waiting for feedback before releasing it.
> >
> > The new version of the Cactus plugin now relies on the newest
Cactus/Ant
> > integration which has completely changed since version 2.0 of the
Maven
> > plugin. Thanks to the new Cactus/Ant, some features have also been
> > added. The plugin now uses the new <cactifywar> and <cactus> Ant
tasks
> > (see http://jakarta.apache.org/cactus/integration/ant/index.html for
> > more details).
> >
> > Note that version 2.1-SNAPSHOT will never get released as 1/ a bug
ad
> > been introduced and 2/ the direction is to use the Cactus/Ant
> > integration which has been changed in Cactus CVS.
> >
> > Please give it a try and report any issue on the Maven mailing
> > lists/JIRA. You can find a read-made test application in
> >
http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
> > if you wish.
> >
> > Thank you
> > -Vincent
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: [Cactus plugin] Full new rewrite
Posted by Vincent Massol <vm...@pivolis.com>.
Note: I'm cc-ing the cactus dev list as it is of interest to both lists
(probably even more to the cactus one and conversation should probably
be moved to there).
See below.
> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 24 May 2003 12:12
> To: dev@maven.apache.org
> Cc: Vincent Massol
> Subject: Re: [Cactus plugin] Full new rewrite
>
> Hello Vincent, hello all.
>
> This _is_ indeed a rework (as you promised not so long ago).
>
> Probably it works as intended, but I would have a few comments. In
order
> to
> be understood, I will have to start with my history with 2.0.
It has not yet been fully tested yet (I had tried it on Resin 2.x and
Tomcat 4.x). I have just fixed a bug to make it work with JBoss 3.2.1.
>
> I am using JBoss 3.x as target container in development cycle.
> As soon as the ant-integration module was used in Cactus plugin I
noticed
> that deployment of artifact (cactified WAR) was not handled quite
properly
> in my particular case. I was (and am) running jboss permanently and
take
> advantage of its hot-deploy feature. Therefore, when trying Cactus
within
> Maven I was naturally expecting to use the same (already started)
JBoss.
> As I checked, the test runner task was prepared to "understand" this,
as
> it
> does not blindly try to start and stop the container. Cool.
> However, it also does not wait for hot-deployment to completely
happen. If
> I
> start the container from scratch, this is not an issue, but if the
> container
> is already started and I do a WAR copy into confname/deploy dir, then
the
> tests are run sometimes _before_ the deployment (using the old WAR) or
> _during_ the deployment. In both cases horrible error logs occur and
of
> course the build fails.
Ah yes. This is definitely a use case I have not tested: hot
redeployment... (I always start the container from scratch). Your help
is very valuable!
>
> Then I decided that if it's not implemented than probably I'm the one
> being
> weird
absolutely not. It's simply that we haven't really looked at hot
deployment so far. With your help, we can hopefully fix it quickly.
> and I did my own hacking: Whipped up my own Ant task doing JMX
> "surveillance" to block the build until proper undeploy/deploy took
place.
> Since I did not want to hack two projects if I could help it, I hacked
> only
> Maven's plugin to replace build-tests-jboss3x.xml from integration jar
"on
> the fly" with my own version that did the JMX waiting.
>
> Now 3.0 kicks in, and I have to say it looks elegant (no more weird
jars
> unpacked locally). But this is bad news for me, since the new kit does
not
> work as I'd expect when the container is already started.
> I took the time to dig in Cactus sources from CVS and it appears
> (confirmed
> by my tests) that:
>
> "If the container is already started, no deployment takes place
(method
> JBoss3xContainer.prepare() is never called ) and tests are run
directly."
> And fail or run whatever WAR they find in there, not necessarily the
fresh
> one.
>
> It is reasonable to suppose that this is intended behavior and that
one
> would expect the caller to make its own deployment beforehand. I can
live
> with that. However, I would like to know what's the projected course
of
> action:
>
> 1. Is this the planned way to go? Then Maven plugin (at least my
version
> but
> maybe I'm not the only one) should take care of deploying the
cactified
> WAR.
> At the very least, there should be a warning somewhere in the
generated
> docs
> that one should do it via <preGoal name="cactus:test" > in its
maven.xml.
> I
> could help with that if needed.
No, that's not the intention I believe. Our goal is to make it the
simplest possible for end users. That said, there are 2 main front-ends
(aka integration) for Cactus for automated builds:
1/ The Ant integration: this is for advanced users who wish to
completely control their builds. There is a <generic> container tag that
can be used in inside the <cactus> task to control everything.
2/ The Maven integration is for end users who want to use Cactus in the
easiest possible manner. It currently supports the most basic uses cases
and my goal is to improve it to support more and more scenarios as I get
feedback from its users, such as what you are reporting.
>
> or
>
> 2. This is a slip in cactus-ant and it will get corrected, such that
when
> the container is already started the deployment still takes place (but
> please, do not forget to JMX-wait for complete deployment or deploy
via
> JMX
> "in place" the cactified WAR). Then the plugin is fine as-is, but
changes
> are strongly required in cactus-ant to support the "developer mode"
usage
> pattern. If this is the case, please-please do not forget the waiting
> stuff,
> otherwise the whole package will get unusable with hot-deploy JBoss,
not
> even in "mode 1" above.
+1. Thanks for the suggestion. Could you send us your JMX-wait
implementation so that we can use it?
>
> Thanks for reading this far; I'm expecting your opinions.
>
Thanks for your feedback.
-Vincent
> Florin
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: <de...@maven.apache.org>
> Cc: <us...@maven.apache.org>
> Sent: Saturday, May 24, 2003 12:12 AM
> Subject: [Cactus plugin] Full new rewrite
>
>
> > Hi,
> >
> > I have just committed a full rewrite of the Maven Cactus plugin. As
it
> > is a rewrite, I have increased the version to 3.0 (it was
2.1-SNAPSHOT
> > before). Note that the 3.0 version is still in development and is
not
> > released yet. I'm waiting for feedback before releasing it.
> >
> > The new version of the Cactus plugin now relies on the newest
Cactus/Ant
> > integration which has completely changed since version 2.0 of the
Maven
> > plugin. Thanks to the new Cactus/Ant, some features have also been
> > added. The plugin now uses the new <cactifywar> and <cactus> Ant
tasks
> > (see http://jakarta.apache.org/cactus/integration/ant/index.html for
> > more details).
> >
> > Note that version 2.1-SNAPSHOT will never get released as 1/ a bug
ad
> > been introduced and 2/ the direction is to use the Cactus/Ant
> > integration which has been changed in Cactus CVS.
> >
> > Please give it a try and report any issue on the Maven mailing
> > lists/JIRA. You can find a read-made test application in
> >
http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
> > if you wish.
> >
> > Thank you
> > -Vincent
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Cactus plugin] Full new rewrite
Posted by Florin Vancea <fv...@maxiq.ro>.
Hello Vincent, hello all.
This _is_ indeed a rework (as you promised not so long ago).
Probably it works as intended, but I would have a few comments. In order to
be understood, I will have to start with my history with 2.0.
I am using JBoss 3.x as target container in development cycle.
As soon as the ant-integration module was used in Cactus plugin I noticed
that deployment of artifact (cactified WAR) was not handled quite properly
in my particular case. I was (and am) running jboss permanently and take
advantage of its hot-deploy feature. Therefore, when trying Cactus within
Maven I was naturally expecting to use the same (already started) JBoss.
As I checked, the test runner task was prepared to "understand" this, as it
does not blindly try to start and stop the container. Cool.
However, it also does not wait for hot-deployment to completely happen. If I
start the container from scratch, this is not an issue, but if the container
is already started and I do a WAR copy into confname/deploy dir, then the
tests are run sometimes _before_ the deployment (using the old WAR) or
_during_ the deployment. In both cases horrible error logs occur and of
course the build fails.
Then I decided that if it's not implemented than probably I'm the one being
weird and I did my own hacking: Whipped up my own Ant task doing JMX
"surveillance" to block the build until proper undeploy/deploy took place.
Since I did not want to hack two projects if I could help it, I hacked only
Maven's plugin to replace build-tests-jboss3x.xml from integration jar "on
the fly" with my own version that did the JMX waiting.
Now 3.0 kicks in, and I have to say it looks elegant (no more weird jars
unpacked locally). But this is bad news for me, since the new kit does not
work as I'd expect when the container is already started.
I took the time to dig in Cactus sources from CVS and it appears (confirmed
by my tests) that:
"If the container is already started, no deployment takes place (method
JBoss3xContainer.prepare() is never called ) and tests are run directly."
And fail or run whatever WAR they find in there, not necessarily the fresh
one.
It is reasonable to suppose that this is intended behavior and that one
would expect the caller to make its own deployment beforehand. I can live
with that. However, I would like to know what's the projected course of
action:
1. Is this the planned way to go? Then Maven plugin (at least my version but
maybe I'm not the only one) should take care of deploying the cactified WAR.
At the very least, there should be a warning somewhere in the generated docs
that one should do it via <preGoal name="cactus:test" > in its maven.xml. I
could help with that if needed.
or
2. This is a slip in cactus-ant and it will get corrected, such that when
the container is already started the deployment still takes place (but
please, do not forget to JMX-wait for complete deployment or deploy via JMX
"in place" the cactified WAR). Then the plugin is fine as-is, but changes
are strongly required in cactus-ant to support the "developer mode" usage
pattern. If this is the case, please-please do not forget the waiting stuff,
otherwise the whole package will get unusable with hot-deploy JBoss, not
even in "mode 1" above.
Thanks for reading this far; I'm expecting your opinions.
Florin
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: <de...@maven.apache.org>
Cc: <us...@maven.apache.org>
Sent: Saturday, May 24, 2003 12:12 AM
Subject: [Cactus plugin] Full new rewrite
> Hi,
>
> I have just committed a full rewrite of the Maven Cactus plugin. As it
> is a rewrite, I have increased the version to 3.0 (it was 2.1-SNAPSHOT
> before). Note that the 3.0 version is still in development and is not
> released yet. I'm waiting for feedback before releasing it.
>
> The new version of the Cactus plugin now relies on the newest Cactus/Ant
> integration which has completely changed since version 2.0 of the Maven
> plugin. Thanks to the new Cactus/Ant, some features have also been
> added. The plugin now uses the new <cactifywar> and <cactus> Ant tasks
> (see http://jakarta.apache.org/cactus/integration/ant/index.html for
> more details).
>
> Note that version 2.1-SNAPSHOT will never get released as 1/ a bug ad
> been introduced and 2/ the direction is to use the Cactus/Ant
> integration which has been changed in Cactus CVS.
>
> Please give it a try and report any issue on the Maven mailing
> lists/JIRA. You can find a read-made test application in
> http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
> if you wish.
>
> Thank you
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-new structure?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2003-05-23 at 18:57, Paulo Silveira wrote:
> Today I ve discovered maven-new, and I am trying to fully understand it.
> Sorry about some stupid questions, but since there is no dev mail
> archives, I am guessing
>
> If Jason/Ben/Michal can help me:
Most of this is Ben's first attempt at getting things working. I haven't
really looked at much of it but I'll try to give you an outline of what
things will probably look like.
> /CLI
> - ok, the class that makes a call to maven through the CLI. this way it
> will be easier to make IDEs plugins
The CLI will simply consist of a class (or two) which contains some
argument parsing logic and an embedded plexus container that will be
run. I don't see xmlrpc being used here.
> /commons
> - what will be here?
Just a base template that the other modules can inherit from.
> /server
> - maybe Ben can explaing me what is this. (btw, there are eclipse
> template comments on the top of the classes :) )
> - It seems that we have a PlexusContainer running somewhere, then
> anyone can ask for the Maven component, to attain some goals and so on,
> throug xmlrpc.
I see this whole module disappearing and a plexus container runtime will
be generated which starts up an xmlrpc listener. Pete and I have
applications running under plexus which work in the same fashion. It
works well.
> - but why will someone want to run a webservice that attains some
> goals? an IDE could run it and then make the calls, is it the idea?
For embedding in IDEs you definitely won't need to make xmlrpc calls.
Again a class with an embedded plexus container that can retrieve the
Maven component and the IDE will work directly with that.
> /plugin
> - what is this? only the really needed plugins?
I will probably revamp this on the weekend at some point. But at the
moment we are focusing on separating out the artifact tool chain so we
can make it a separate project.
> About plexus, is there any place that has a better doc (or any doc at
> all :) )? What is the relationship between plexus and avalon?
Plexus in its first forms was a straight attempt at an Avalon container.
I soon realized that I need more in some cases and Plexus is now a tool
for making different kinds of containers. But Plexus supports the Avalon
container API which is what is used for all the components ATM.
> At the end, how will the jars be related? I mean, maven-cli will calls
> maven-core, which can call any plugin to attain some goals, since it has
> the PluginManager. What about the server? Will we have a new .bat and
> .sh?
Ultimately any of the harnesses for short-lived or long-lived processes
will interact with the Maven component. The CLI will be short-lived and
the server and IDE will be long-lived processes. I'm sure there will
some variations and people can always make additional harnesses. Some
may want to use the Maven component directly in IDEs or they may want
the IDE to use a shared Maven server. I'm not really going to try and
predict usage. I just want it to be easy to embed the use of Maven
anywhere and I hope to be able to do that this weekend with a small
embeddor class I'm working on in Plexus.
> Maven-new will completely replace maven in beta-11?
Currently we are working on separating out the artifact related tools.
So when that is done and everything is tested and backward compatible I
hope to strip out all the analagous classes in the older maven code and
replace it with the new stuff we're working on. The new stuff will all
be component based so it should be much easier to write and test
individual components if you need to replace something like making a new
type of downloader or repository layout component if you really wanted
to. It will also include the transitive dependency stuff, new downloader
code and basically a revamped artifact system with all the kudos going
to Michal.
> BTW, pretty nice idea to get an around for all the getters, this way you
> dont need to modify every getter to see if his parent would return sth
> different than null...
Yes, I like that idea. Gilles Dodinet actually fixed it up and made it
work like it should have in the first place :-)
> ------------------------
> Paulo Silveira
> http://www.paulo.com.br/
> http://www.guj.com.br/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-new structure?
Posted by Ben Walding <de...@walding.com>.
Probably worth taking a look at
http://nagoya.apache.org/wiki/apachewiki.cgi?Maven/MavenNG
Explains some of my strangeness. Jason may have other plans, but I have
the documentation! Hazzar!
Essentially the process goes like this
launch the server (or don't)
launch the client
- if the server is specified connect to it
- otherwise, internally launch a server
- use xml-rpc to control the server
Now as to whether an ide interface would use xml-rpc to connect to an in
process server - not sure. I doubt the overhead is very high and it
would mean there would never be any contention as to whether the ide was
starting the container properly or not.
Paulo Silveira wrote:
>Today I ve discovered maven-new, and I am trying to fully understand it.
>Sorry about some stupid questions, but since there is no dev mail
>archives, I am guessing
>
>If Jason/Ben/Michal can help me:
>
>/CLI
> - ok, the class that makes a call to maven through the CLI. this way it
>will be easier to make IDEs plugins
>/commons
> - what will be here?
>/server
> - maybe Ben can explaing me what is this. (btw, there are eclipse
>template comments on the top of the classes :) )
> - It seems that we have a PlexusContainer running somewhere, then
>anyone can ask for the Maven component, to attain some goals and so on,
>throug xmlrpc.
> - but why will someone want to run a webservice that attains some
>goals? an IDE could run it and then make the calls, is it the idea?
>/plugin
> - what is this? only the really needed plugins?
>
>About plexus, is there any place that has a better doc (or any doc at
>all :) )? What is the relationship between plexus and avalon?
>
>At the end, how will the jars be related? I mean, maven-cli will calls
>maven-core, which can call any plugin to attain some goals, since it has
>the PluginManager. What about the server? Will we have a new .bat and
>.sh?
>
>Maven-new will completely replace maven in beta-11?
>
>BTW, pretty nice idea to get an around for all the getters, this way you
>dont need to modify every getter to see if his parent would return sth
>different than null...
>
>------------------------
>Paulo Silveira
>http://www.paulo.com.br/
>http://www.guj.com.br/
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
maven-new structure?
Posted by Paulo Silveira <pa...@paulo.com.br>.
Today I ve discovered maven-new, and I am trying to fully understand it.
Sorry about some stupid questions, but since there is no dev mail
archives, I am guessing
If Jason/Ben/Michal can help me:
/CLI
- ok, the class that makes a call to maven through the CLI. this way it
will be easier to make IDEs plugins
/commons
- what will be here?
/server
- maybe Ben can explaing me what is this. (btw, there are eclipse
template comments on the top of the classes :) )
- It seems that we have a PlexusContainer running somewhere, then
anyone can ask for the Maven component, to attain some goals and so on,
throug xmlrpc.
- but why will someone want to run a webservice that attains some
goals? an IDE could run it and then make the calls, is it the idea?
/plugin
- what is this? only the really needed plugins?
About plexus, is there any place that has a better doc (or any doc at
all :) )? What is the relationship between plexus and avalon?
At the end, how will the jars be related? I mean, maven-cli will calls
maven-core, which can call any plugin to attain some goals, since it has
the PluginManager. What about the server? Will we have a new .bat and
.sh?
Maven-new will completely replace maven in beta-11?
BTW, pretty nice idea to get an around for all the getters, this way you
dont need to modify every getter to see if his parent would return sth
different than null...
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org