"Kevin Jackson" <[EMAIL PROTECTED]> wrote on 11/15/2006 07:07:38 PM:
> > The way I've setup things I can see the changed jsp without calling > > any maven target. There's more details of my solution here > > http://www.nabble.com/Eclipse-war-builder-tf2371898s177.html#a6646490 > > Another fellow wrote a custom eclipse plugin to help him. > > Could you go into more details? I've followed what I could from your > post ^^ but I still cannot get Tomcat to deploy just the context.xml > file and use the target directory as an exploded webapp. My guess is > that I've setup tomcat incorrectly, but a working example of what to > do would be great (I also tried the eclipse war builder thing and > again it didn't work for me). Here's a writeup I did for the team. I'll do my best to answer any questions that it doesn't clarify. Preliminaries You'll need to edit a file in your tomcat installation to allow access to the manager webapp. These instructions are based upon tomcat 5.5.17, but should be similar for any 5.x installation. If not, please update this wiki once it is figured out. In {tomcat-install-dir}/conf/tomcat-users.xml add the following: <user username="admin" password="" roles="tomcat,manager,admin"/> inside the <tomcat-users> element. Go to http://localhost:8080/manager and undeploy your application if it is already there. Also remove any war files and directories for your app under the webapps directory. (Re)start tomcat and you're ready. Maven Targets Now you can do: mvn compile war:inplace tomcat:inplace as your initial setup. You should now be able to see your deployed app in tomcat. Editing JSPs in eclipse will be seen immediately upon a refresh of the web page. If you edit any Java classes that the JSPs depend upon, you can do: mvn compile war:inplace to get tomcat to see the updates. If at any time your context.xml file changes, you can tell tomcat about it by doing: mvn tomcat:inplace I haven't tried this, but it might be useful to modify the eclipse settings to direct compiled classes into the WEB-INF/classes directory. This should remove the need to ever do mvn compile war:inplace since a compile inside eclipse would put the modified classes there. Then only when the context.xml file changes would maven need to be involved. Behind the Scenes So, how does this work? The context.xml file lives in src/main/resources and the pom.xml is configured to filter this. That means we can do variable substitution. The context.xml file uses a variable that is based upon ${basedir} which maven knows as the directory the pom.xml files lives within. So, we can use this to tell tomcat to look inside the project directory for the exploded webapp. war:inplace is a built-in maven goal that knows to create the exploded webapp inside src/main/webapp. However, this goal does not have any prerequisites, so whenever you use it, you must also do a compile (or test if you want to run unit tests too). war:inplace actually copies the external jars into WEB-INF/lib and the compiled classes into WEB-INF/classes, so subversion needs to be configured to ignore these (by adding a svn:ignore property to the WEB-INF directory ? I've already done this for SpecialLoans). Additionally, the pom.xml has been modified to tell the clean target to additionally delete those directories. There's a feature request in maven that will help simplify some of this, like allowing the war:inplace to require compile and test as prerequisites, but due to various reasons, it can't be done in maven 2.0.4. We can update this wiki page when this changes. POM Involvement Here are the relevant sections of the pom.xml that must be set in order for the whole scheme above to work. At some point this, or something similar, should become part of our basepom and archetypes, but until then, the information is preserved. <properties> <docbase.on.server>${basedir}/src/main/webapp</docbase.on.server> <webapp.reloadable>true</webapp.reloadable> </properties> <build> ... <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> <plugins> ... <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.0-SNAPSHOT</version> <configuration> <update>true</update> <mode>context</mode> <contextFile>target/classes/context.xml</contextFile> </configuration> </plugin> <plugin> <!-- clean up from war:inplace --> <artifactId>maven-clean-plugin</artifactId> <configuration> <filesets> <fileset> <directory>${basedir}/src/main/webapp/WEB-INF/lib</directory> </fileset> <fileset> <directory>${basedir}/src/main/webapp/WEB-INF/classes</directory> </fileset> </filesets> </configuration> </plugin> The context.xml lives in src/main/resources and looks like this: <Context docBase="${docbase.on.server}" reloadable="${webapp.reloadable}"> ... Greg Vaughn [EMAIL PROTECTED] ====================================================================== Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. ======================================================================
