Age Mooy wrote:
I suppose I should mention my tomcat plugin[1] here, posted on this list last week. This gives you two more options for getting your webapp onto tomcat, using its management interface: 'install' and 'deploy'.You can point tomcat at ${maven.build.dir}/${pom.id} in its server.xml file and run your webapp from there.The only (tiny) problem is that now you have to run war:webapp to deploy any changes, even for changed templates, images, etc. I use the maven console so running war:webapp takes about 1 second.
The tomcat:deploy goal uploads the war file to tomcat using a PUT request. The war file is then unpacked, and started. This can obviously take time on big webapps. You can mitigate this by designing your webapp so it doesn't include static content[2].
The other option is tomcat:install. This tells tomcat where to find the war file. Tomcat will then run your webapp directly out of the war file without moving it or unpacking it (it sets the document base to point at your .war file). This is obviously faster than deploying it, but means you can't have writable directories in your webapp (I notice Age had a 'logs' dir in his) - this is a good practice as it means you can safely replace the application without losing its data[3].
The main advantage of tomcat:install though is that it is supposed to be able to insert extra info in the <Context> for your webapp in server.xml. This doesnt matter for lone developers, but in a team situation, it means everyone gets the changes from CVS. Unfortunately this feature seems a bit flaky to me :)
<opinion>
If you're developing JSPs, Age's solution is far better - both of the tomcat goals I've described above will cause all your JSPs to need recompilation. If you're mainly developing servlets/filters, or otherwise messing with your web.xml, then the tomcat:install is a useful alternative[4]. If for some reason you need to work with a remote server, then tomcat:deploy is best.
</opinion>
Cheers,
-Baz
[1] There were a couple bugs in the plugin, I've found since. The 'stop' goal calls 'start' - doh! Also 'remove' depends on 'war:war', this is unnecessary.
[2] This also allows static content to be deployed without bottlenecking at the java developers. Recently we made this change to one of our webapps, dropping its size from 18Mb to 4Mb (the 4Mb is mainly jars we depend on, the other 16Mb came from PDFs, images, etc that were part of the site).
[3] NB you can't do an 'install' twice - in emacs I have M-x compile set up to do 'maven -Ef project.xml tomcat:remove tomcat:install' to do a 'reinstall'.
[4] I'm not sure if tomcat:install is better here. Age's solution makes each context reloadable to pick up servlet changes. We have many webapps we work on for different customers, and going in to server.xml to set 'reloadable="true"' for each one gets old fast. However I think you can make the default context reloadable, in which case only the <Context> trick is an improvement over Age's solution; also IIRC with reload=true tomcat will still not detect changes to 'web.xml'.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
