On 03/11/05, Brett Porter <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
