Raised http://jira.codehaus.org/browse/MNG-1649 to track this.

Mark

On 03/11/05, Mark Hobson <[EMAIL PROTECTED]> wrote:
> 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]

Reply via email to