The development process uses the Tomcat MAVEN plugin to continuously and quickly deploy Web projects

I used Hudson to deploy my Web project to tomcat on the test server in my usual work. The Hudson itself is integrated with SVN, Git, MAVEN, and supports the addition of various plugins. But if you use Hudson, I need to configure two tasks: one to package the project into a war, and the other to deploy the packaged war package to Tomcat on the target server. Although the task only needs to be configured once, each time you modify the code submission, you have to switch to the build Now button on the Hudson Build task page of the browser point and then jump to another page to see if there is an error. It's annoying to find that the Tomcat Maven plugin supports direct deployment of the project into Tomcat, which is finally done after a try.

There are a lot of articles on this topic on the Internet, and the process is much the same, but the main thing in this article is to record the pits I've stepped on in this process and suggestions for such a deployment.

1. Preparatory work

Download the installation and configure Tomcat and Maven.

Prepare a MAVEN Web project.

? 2. MAVEN deployment Web project to tomcat configuration ?

? 2.1. Configuring the Tomcat role ?

maven automatic deployment is actually tuned to the manager feature in the Tomcat installation directory. In order to access the Http://localhost:8080/manager page normally, we need to modify the Tomcat-users.xml in the $tomcat_home/conf directory:

<tomcat-users> <role rolename= "Tomcat"/> <role rolename= "manager"/> <role rolename= "Manager-gui "/> <role rolename=" Manager-script "/> <role rolename=" Admin-gui "/> <user username=" Tomcat "password = "Tomcat" roles= "Tomcat,manager, Manager-gui,manager-script,admin-gui"/></tomcat-users>

2.2. Modify Pom.xml add tomcat Maven Plugin

I use the tomcat7,pom.xml to add the following configuration:

<properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>< spring.version>3.2.2.release</spring.version><finalname>web-loab</finalname></ Properties><build><plugins><plugin><groupid>org.apache.tomcat.maven</groupid> <artifactid>tomcat7-maven-plugin</artifactid><configuration><url>http://localhost:8080 /manager/text</url><server>tomcat</server><username>tomcat</username>< Password>tomcat</password><path>/${finalname}</path></configuration></plugin> </plugins></build>

Above username, password from tomcat-users.xml. Server is the Tomcat server name. Path is the way to access the app. The URL specifies the Tomcat Management page path.

2.3. Modify MAVEN's Settings.xml

Locate Settings.xml in the $USER_HOME/.M2 directory and add the server node:

<servers> <server> <id>tomcat</id> <username>tomcat</username> &L T;password>tomcat</password> </server></servers>

the above username and password are still the same as in Tomcat-users.xml, with the same ID as the server in 2.2

2.4. Deploy the project to Tomcat

First make sure that the Tomcat server is started, then CD to the project root, and run the following command:

MVN Clean Tomcat7:redeploy

The deployment was successful as follows:

We can then locate the newly deployed war package under the WebApps directory of the Tomcat installation directory.

The first deployment is with the Tomcat7:deploy command, which can be redeployed with the Tomcat7:redeploy Command (which is recommended for unification), and the commands supported by the Tomcat Maven plugin include: Run, shutdown, run-war-only, Exec-war, standalone-war-only, deploy, Standalone-war, Undeploy, Run-war, redeploy, etc.

? 3. Step over the pit ?

Looking at the above process, it seems to be very smooth, but the world is always not so smooth. Here are a few of the pits I've stepped on.

? 3.1, Windows system, redeploy process can not delete the old project directory ?

The error message is in the Catalina log file under $TOMCAT _home/logs, as follows:

Information: undeploying context [/web-loab] October 11, 2014 3:52:26 pm Org.apache.catalina.startup.ExpandWar deletedir grave: [D:\tomcat\ Apache-tomcat-7.0.56\webapps\web-loab\web-inf] could not being completely deleted. The presence of the remaining files may cause problems

Probably because TOMCAT is still using this directory and cannot be deleted, it must be modified $TOMCAT _home/conf/context.xml:

<context antijarlocking= "true" antiresourcelocking= "true" >

? 3.2, Servelt.class offending ?

This problem should not fall within the scope of this article, but it may cause the Web project to start up but can not access, the error message is as follows:

October 11, 2014 3:46:29 pm org.apache.catalina.loader.WebappClassLoader validatejarfile Info: validatejarfile (D:\tomcat\ Apache-tomcat-7.0.56\webapps\web-loab\web-inf\lib\servlet-api-6.0.29.jar)-jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending Class:javax/servlet/servlet.class

The reason is that there is servlet-api.jar in the Web-inf/lib directory for a Web project under the WebApps directory, delete it, and specify Servelt-api.jar's scope as provided in Pom.xml:

<dependency><groupid>org.apache.tomcat</groupid><artifactid>servlet-api</artifactid ><version>6.0.29</version><scope>provided</scope></dependency>

3.3. Version issues

Make sure that the Java build path for your Web project uses the JDK version, the compiled JDK version of Java compiler, and the Java version in project Facets.

If the TOMCAT6 is used, the Tomcat6-maven-plugin is configured in Pom.xml, and Tomcat7-maven-plugin is used if TOMCAT7 is used. or by default with Tomcat-maven-plugin.

4. Some suggestions for deploying a project using the Tomcat Maven plugin

This approach enables continuous and rapid deployment. But it has some limitations:

• Requires direct access to the network segment of the Tomcat server from the local development environment

• The history deployment package cannot be preserved

Therefore, the initial recommendation is to use this deployment method only in the development environment, and with the SVN, Git and other version control software to do two internal conventions:

• All deployable version codes must be checked in to a branch named Deploy-xx, XX represents the currently deployable version, and then to the DEPLOY-XX branch redeploy project

• when new features are added later, you need to create another deploy branch and increase the version number. This allows you to use version control software to help us preserve the Historical deployable code (which addresses the second limitation mentioned above). Especially with multiple project integrations, it is best to ensure that each project's deploy branch has the same version suffix as each time it is integrated. This facilitates collective rollback of individual project code

Finish!

The development process uses the Tomcat MAVEN plugin to continuously and quickly deploy Web projects