You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2005/10/31 22:24:20 UTC
Re: [m2] Plugins that depend on other plugin goals
On 31/10/05, Brett Porter <br...@gmail.com> wrote:
> I see - you are right, that was by design.
Thanks for clarifying, it seemed that way but wasn't sure if I was
missing something.
> I'll have to think about the best path forward on this. Can we move it
> to the dev list?
Sure, I've posted to dev and cc'ed to user, in case people are
tracking this. Just remember to un-cc user on reply..
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Plugins that depend on other plugin goals
Posted by Mark Hobson <ma...@gmail.com>.
Raised http://jira.codehaus.org/browse/MNG-1649 to track this.
Mark
On 03/11/05, Mark Hobson <ma...@gmail.com> wrote:
> On 03/11/05, Brett Porter <br...@apache.org> wrote:
> > Can you reiterate why you need tomcat:exploded and tomcat:inplace
> > instead of just using the war:* goals?
> >
> > This was probably discussed in the users list thread, but good to
> > elaborate here. I find it really helpful to see how you intend to use
> > the plugin, then look at how that would be implemented.
>
> Sure, always the best way to take things forward.
>
> The situation is that tomcat can be deployed to in the following ways:
>
> 1) a war file via http put (with optional context.xml in war)
> 2) a war file via url (with optional context.xml)
> 3) an exploded war directory via url (with optional context.xml)
> 4) a context xml file via url
>
> So in the context of mvn, each of the above have the following prerequisites:
>
> 1&2) war:war
> 3&4) war:exploded or war:inplace
>
> Without these prerequisites the plugin could all too easily deploy
> stale code, which ideally should avoided if at all possible.
>
> So to align the tomcat plugin goals with the war goals, I intended to
> split the deploy goal up and utilise a mode config param as follows:
>
> * tomcat:deploy
> mode=war - deploys the war file using method (1)
> mode=context - deploys the context file using method (4)
> mode=both - same as mode=war
>
> * tomcat:exploded
> mode=war - deploys the exploded war target dir using method (3)
> mode=context - deploys the context.xml using method (4)
> mode=both - deploys the exploded war target dir with context.xml
> using method (3)
>
> * tomcat:inplace
> mode=war - deploys the exploded war source dir using method (3)
> mode=context - deploys the context.xml using method (4)
> mode=both - deploys the exploded war source dir with context.xml
> using method (3)
>
> Method (2) is not supported since it's identical to (1) but
> constrained by the war url being accessible by tomcat.
>
> These goals then allow the following deploy-specific configuration
> params with corresponding default values:
>
> * all deploy goals:
> contextFile =
> "${project.build.directory}/${project.build.finalName}/META-INF/context.xml"
> mode = "war"
> * tomcat:deploy only:
> warFile = "${project.build.directory}/${project.build.finalName}.war"
> * tomcat:exploded only:
> warDirectory = "${project.build.directory}/${project.build.finalName}"
> * tomcat:inplace only:
> warSourceDirectory = "${basedir}/src/main/webapp"
>
> So this allows all config params to reside alongside one another in
> the pom and lets the user decide which type of deployment to use at
> runtime - deploy, exploded or inplace.
>
> I'm aware that this all seems overly complicated to just deploy a
> webapp, but I'm trying to support all tomcat deployment methods with
> minimal pom configuration.
>
> So as you can see each deploy goal has a prerequisite of the
> corresponding war goal - tomcat:exploded depends on war:exploded, etc.
> Now the problems of depending on just the package phase are as
> follows:
>
> * tomcat:deploy - none
> * tomcat:exploded - the zipping of the war file is redundant
> * tomcat:inplace - war:war puts the exploded war in the war target
> dir, not the war source dir as per war:inplace. This means the user
> misses out on potential hot-deployment features as the war files are
> edited in place.
>
> I'm also trying to see this from a general j2ee container
> point-of-view rather than just specifically tomcat, as I'd like to
> transfer the outcome of this design to the cargo plugin which
> obviously must support all container features - jetty's inplace
> hot-deployment, tomcat's exploded war deployment, etc.
>
> Sorry for the length of this mail, but any ideas appreciated! I'm
> happy to restructure the goals to avoid the lifecycle/packaging
> problem, but we still need to support all deployment methods.
>
> Cheers,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Plugins that depend on other plugin goals
Posted by Mark Hobson <ma...@gmail.com>.
On 03/11/05, Brett Porter <br...@apache.org> wrote:
> Can you reiterate why you need tomcat:exploded and tomcat:inplace
> instead of just using the war:* goals?
>
> This was probably discussed in the users list thread, but good to
> elaborate here. I find it really helpful to see how you intend to use
> the plugin, then look at how that would be implemented.
Sure, always the best way to take things forward.
The situation is that tomcat can be deployed to in the following ways:
1) a war file via http put (with optional context.xml in war)
2) a war file via url (with optional context.xml)
3) an exploded war directory via url (with optional context.xml)
4) a context xml file via url
So in the context of mvn, each of the above have the following prerequisites:
1&2) war:war
3&4) war:exploded or war:inplace
Without these prerequisites the plugin could all too easily deploy
stale code, which ideally should avoided if at all possible.
So to align the tomcat plugin goals with the war goals, I intended to
split the deploy goal up and utilise a mode config param as follows:
* tomcat:deploy
mode=war - deploys the war file using method (1)
mode=context - deploys the context file using method (4)
mode=both - same as mode=war
* tomcat:exploded
mode=war - deploys the exploded war target dir using method (3)
mode=context - deploys the context.xml using method (4)
mode=both - deploys the exploded war target dir with context.xml
using method (3)
* tomcat:inplace
mode=war - deploys the exploded war source dir using method (3)
mode=context - deploys the context.xml using method (4)
mode=both - deploys the exploded war source dir with context.xml
using method (3)
Method (2) is not supported since it's identical to (1) but
constrained by the war url being accessible by tomcat.
These goals then allow the following deploy-specific configuration
params with corresponding default values:
* all deploy goals:
contextFile =
"${project.build.directory}/${project.build.finalName}/META-INF/context.xml"
mode = "war"
* tomcat:deploy only:
warFile = "${project.build.directory}/${project.build.finalName}.war"
* tomcat:exploded only:
warDirectory = "${project.build.directory}/${project.build.finalName}"
* tomcat:inplace only:
warSourceDirectory = "${basedir}/src/main/webapp"
So this allows all config params to reside alongside one another in
the pom and lets the user decide which type of deployment to use at
runtime - deploy, exploded or inplace.
I'm aware that this all seems overly complicated to just deploy a
webapp, but I'm trying to support all tomcat deployment methods with
minimal pom configuration.
So as you can see each deploy goal has a prerequisite of the
corresponding war goal - tomcat:exploded depends on war:exploded, etc.
Now the problems of depending on just the package phase are as
follows:
* tomcat:deploy - none
* tomcat:exploded - the zipping of the war file is redundant
* tomcat:inplace - war:war puts the exploded war in the war target
dir, not the war source dir as per war:inplace. This means the user
misses out on potential hot-deployment features as the war files are
edited in place.
I'm also trying to see this from a general j2ee container
point-of-view rather than just specifically tomcat, as I'd like to
transfer the outcome of this design to the cargo plugin which
obviously must support all container features - jetty's inplace
hot-deployment, tomcat's exploded war deployment, etc.
Sorry for the length of this mail, but any ideas appreciated! I'm
happy to restructure the goals to avoid the lifecycle/packaging
problem, but we still need to support all deployment methods.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Plugins that depend on other plugin goals
Posted by Brett Porter <br...@apache.org>.
Can you reiterate why you need tomcat:exploded and tomcat:inplace
instead of just using the war:* goals?
This was probably discussed in the users list thread, but good to
elaborate here. I find it really helpful to see how you intend to use
the plugin, then look at how that would be implemented.
- Brett
Mark Hobson wrote:
> On 02/11/05, Kenney Westerhof <ke...@apache.org> wrote:
>
>>On Wed, 2 Nov 2005, Mark Hobson wrote:
>>
>>Just some thoughts:
>>
>>The 'war' packaging _NEEDS_ a .war to be produced in case it will be used
>>in an ear. If you replace the war packaging by 'exploded', then there is
>>no artifact which will fail the install goal etc.
>
>
> This is true, but I guess the lifecycle would only be modified if the
> tomcat:exploded goal was present in the list of goals to execute -
> kinda smells of undeterministic behaviour though..
>
>
>>People want to test their webapps without running the war:war goal
>>since it is so slow. I can understand that.
>>
>>Perhaps a new lifecycle phase 'dev' or something, just before 'package',
>>might be useful in this case.
>
>
> Maybe a 'prepare-package' phase? I'm not sure how this would work
> with war:inplace though, since the results of this goal are mutually
> exclusive to the war:exploded and war:war goals.
>
>
>>Another way would be to optimize the WarMojo to update the .war instead of
>>recreating it each time. Then the war:war will always run, and you bind
>>war:exploded to the package phase too. This will eliminate the performance
>>penalty, I hope.
>
>
> This would certainly help, although tomcat:inplace still wouldn't be
> able to depend on war:inplace.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Plugins that depend on other plugin goals
Posted by Mark Hobson <ma...@gmail.com>.
On 02/11/05, Kenney Westerhof <ke...@apache.org> wrote:
> On Wed, 2 Nov 2005, Mark Hobson wrote:
>
> Just some thoughts:
>
> The 'war' packaging _NEEDS_ a .war to be produced in case it will be used
> in an ear. If you replace the war packaging by 'exploded', then there is
> no artifact which will fail the install goal etc.
This is true, but I guess the lifecycle would only be modified if the
tomcat:exploded goal was present in the list of goals to execute -
kinda smells of undeterministic behaviour though..
> People want to test their webapps without running the war:war goal
> since it is so slow. I can understand that.
>
> Perhaps a new lifecycle phase 'dev' or something, just before 'package',
> might be useful in this case.
Maybe a 'prepare-package' phase? I'm not sure how this would work
with war:inplace though, since the results of this goal are mutually
exclusive to the war:exploded and war:war goals.
> Another way would be to optimize the WarMojo to update the .war instead of
> recreating it each time. Then the war:war will always run, and you bind
> war:exploded to the package phase too. This will eliminate the performance
> penalty, I hope.
This would certainly help, although tomcat:inplace still wouldn't be
able to depend on war:inplace.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Plugins that depend on other plugin goals
Posted by Kenney Westerhof <ke...@apache.org>.
On Wed, 2 Nov 2005, Mark Hobson wrote:
Just some thoughts:
The 'war' packaging _NEEDS_ a .war to be produced in case it will be used
in an ear. If you replace the war packaging by 'exploded', then there is
no artifact which will fail the install goal etc.
People want to test their webapps without running the war:war goal
since it is so slow. I can understand that.
Perhaps a new lifecycle phase 'dev' or something, just before 'package',
might be useful in this case.
Another way would be to optimize the WarMojo to update the .war instead of
recreating it each time. Then the war:war will always run, and you bind
war:exploded to the package phase too. This will eliminate the performance
penalty, I hope.
-- Kenney
> Hi all,
>
> To summarise the problem here, we need a way for plugins to depend on
> other plugin's goals. The example use case is the tomcat:exploded
> goal which needs to depend on war:exploded, and not war:war since this
> has a performance hit. The tomcat:exploded goal depends on the
> package phase, so we need to execute the package phase but in a
> slightly modified lifecycle.
>
> We have the components.xml method which allows a new lifecycle to be
> defined for a new packaging, but we need to keep the packaging as war.
> We also have the lifecycles.xml method which overlays extra goals on
> top of the current lifecycle, but we need to replace one goal in the
> lifecycle with another.
>
> I'm no m2 lifecycle guru here, but a couple of ideas:
>
> 1) Allow multiple lifecycles per packaging. Does the lifecycle id
> element not cater for this already? If so could a mojo inflict an
> alternative lifecycle which it defines for the given packaging?
>
> 2) Override existing core lifecycles with ones supplied by the plugin.
> I tried doing this but the core war lifecycle always took precedence.
>
> 3) The ability to unbind goals from phases in the lifecycle. There
> doesn't seem to a mechanism to do this AFAIK?
>
> Any discussion appreciated.
>
> Cheers,
>
> Mark
>
> On 31/10/05, Mark Hobson <ma...@gmail.com> wrote:
> > On 31/10/05, Brett Porter <br...@gmail.com> wrote:
> > > I see - you are right, that was by design.
> >
> > Thanks for clarifying, it seemed that way but wasn't sure if I was
> > missing something.
> >
> > > I'll have to think about the best path forward on this. Can we move it
> > > to the dev list?
> >
> > Sure, I've posted to dev and cc'ed to user, in case people are
> > tracking this. Just remember to un-cc user on reply..
> >
> > Cheers,
> >
> > Mark
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Plugins that depend on other plugin goals
Posted by Mark Hobson <ma...@gmail.com>.
Hi all,
To summarise the problem here, we need a way for plugins to depend on
other plugin's goals. The example use case is the tomcat:exploded
goal which needs to depend on war:exploded, and not war:war since this
has a performance hit. The tomcat:exploded goal depends on the
package phase, so we need to execute the package phase but in a
slightly modified lifecycle.
We have the components.xml method which allows a new lifecycle to be
defined for a new packaging, but we need to keep the packaging as war.
We also have the lifecycles.xml method which overlays extra goals on
top of the current lifecycle, but we need to replace one goal in the
lifecycle with another.
I'm no m2 lifecycle guru here, but a couple of ideas:
1) Allow multiple lifecycles per packaging. Does the lifecycle id
element not cater for this already? If so could a mojo inflict an
alternative lifecycle which it defines for the given packaging?
2) Override existing core lifecycles with ones supplied by the plugin.
I tried doing this but the core war lifecycle always took precedence.
3) The ability to unbind goals from phases in the lifecycle. There
doesn't seem to a mechanism to do this AFAIK?
Any discussion appreciated.
Cheers,
Mark
On 31/10/05, Mark Hobson <ma...@gmail.com> wrote:
> On 31/10/05, Brett Porter <br...@gmail.com> wrote:
> > I see - you are right, that was by design.
>
> Thanks for clarifying, it seemed that way but wasn't sure if I was
> missing something.
>
> > I'll have to think about the best path forward on this. Can we move it
> > to the dev list?
>
> Sure, I've posted to dev and cc'ed to user, in case people are
> tracking this. Just remember to un-cc user on reply..
>
> Cheers,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org