[ http://jira.codehaus.org/browse/MNG-785?page=all ]
Brett Porter closed MNG-785:
----------------------------
Assign To: Brett Porter
Resolution: Fixed
closing since this is checked in
> m2 tomcat plugin
> ----------------
>
> Key: MNG-785
> URL: http://jira.codehaus.org/browse/MNG-785
> Project: Maven 2
> Type: New Feature
> Components: maven-plugins
> Versions: 2.0-beta-1
> Reporter: Mark Hobson
> Assignee: Brett Porter
> Attachments: maven-tomcat-plugin.tar.gz, maven-tomcat-plugin.zip
>
>
> See attached for an initial stab at a m2 Tomcat plugin. The plugin provides
> the following goals:
> tomcat:deploy
> tomcat:undeploy
> tomcat:reload
> tomcat:start
> tomcat:stop
> It's geared towards Tomcat 5.5 in which the install/remove commands are
> depreciated in preference of deploy/undeploy. It shouldn't be much work to
> add these for Tomcat 5.0 users if necessary.
> I tried to keep the config to a minimum since the vast number of deployment
> options that Tomcat provides tends to complicate plugins. The core config
> params for all tasks are:
> url - the Tomcat manager URL (default = "http://localhost:8080/manager";)
> username - the Tomcat manager username (default = "admin")
> password - the Tomcat manager password (default = "")
> charset - the Tomcat manager request URL encoding charset (default =
> "ISO-8859-1")
> path - the web context path (default = "/${project.build.finalName}")
> The tomcat:deploy goal requires further parameters to customise the type of
> deployment. After considering the various deployment methods supported by
> manager, I decided that the project-centric ones applicable to a m2 plugin
> come down to three modes of operation:
> remote
> - the war is deployed via a HTTP PUT to manager
> - war plugin mode must be "normal" (i.e. not exploded)
> - suitable for cross-network
> local
> - the war is deployed by supplying a path to the war file/dir
> - the war plugin mode config param determines whether the war is deployed as
> a file or as a dir
> - suitable for localhost tomcat
> inplace
> - the war is deployed via a context.xml file that refers to the war dir
> - the war plugin mode must be exploded
> - suitable for dev
> The other Tomcat deployment methods didn't seem too useful for
> project-orientation deployment - they are summarised here:
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%20Application%20from%20a%20Local%20Path
> So the tomcat:deploy specific config params are:
> mode - "remote", "local" or "inplace" (default = "remote")
> war - the war file path (default =
> "${project.build.directory}/${project.build.finalName}.war")
> warDir - the war dir path (default =
> "${project.build.directory}/${project.build.finalName}")
> config - the context.xml path (default =
> "${project.build.directory}/${project.build.finalName}/META-INF/context.xml")
> update - whether to undeploy before deploying (default = false)
> When deploying inplace the context.xml Context/@docBase attribute needs to be
> set to the war dir. I noticed the discussion on the m2 mailing list
> regarding resource filtering, so hopefully that can perform this task pre-war.
> The code is inspired by the Tomcat Ant tasks, but rewritten for m2. This is
> my first m2 plugin so any constructive comments are welcome! In particular,
> feedback on the following would be appreciated:
> - opinions on the remote/local/inplace mode of operations
> - any config options I've missed
> - is the method of introspecting the war plugin config the norm, or is there
> a nicer way?
> You're welcome to the code & I'm happy to adopt this plugin time-permitting.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
