1. The directory structure of the web project
For Java-based web projects, the standard packaging method is WAR. Compared with JAR, it contains more content, such as JSP files, Servlets, Java classes, web.xml configuration files, dependent JAR packages, static web resources (HTML, CSS, JavaScript), etc.
A typical WAR file has the following directory structure:
—war/
+ META-INF /
+ WEB-INF/
| + classes/
| | + ServletA.class
| | + config.properties
| | + ...
| + web.xml
+ img/
+ css/
+ js/
+ index.html
+ sample.jsp
A WAR package contains at least two subdirectories: META-INF and WEB-INF, the former contains some packaging metadata information; the latter is the core of the WAR package, and WEB-INF must contain a Web resource description file web.xml, Its subdirectory classes contains all the classes of the web project, and another subdirectory lib contains all the dependent JAR packages of the web project. Both the classes and lib directories are added to the Classpath at runtime. In addition, the WAR package will contain many Web resources, such as html, jsp, pictures, etc.
Maven also has a general convention for the layout structure of web projects. The specified packaging method that must be displayed for web projects is war.
<project> <modelVersion>4.0.0</modelVersion> <groupId>com.gqshao.myapp</groupId> <artifactId>project-a</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <name>project-a</name> </project>
The class and resource files of the web project are the same as the general JAR projects, and the default locations are src/main/java and src/main/resources
The special feature of the web project is that it also has a web resource directory whose default location is src/main/webapp/. The Maven directory structure of a typical web project is as follows:
+ project
+ pom.xml
+ src
| + main/
| | + java/
| | | + ServletA.class
| | | ...
| | + ...
| + resources/
| | + config.properties
| + webapp/
| | + WEB-INF/
| | | + web.xml /
| | + img/
| | + css/
| | + js/
| | + index.html/
| | + sample.jsp/
| + test/
| | + java/
| + resources
In the src/main/webapp/ directory, it must contain a subdirectory WEB-INF, which must also contain the web.xml file
2. POM for web project
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.gqshao.myapp</groupId> <artifactId>learn-maven</artifactId> <packaging>war</packaging> <version>0.0.1-SNAPSHOT</version> <name>myapp.learn_maven Maven Webapp</name> <properties> <springframework.version>3.2.2.RELEASE</springframework.version> <junit.version>4.7</junit.version> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.4</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet.jsp</groupId> <artifactId>jsp-api</artifactId> <version>2.0</version> <scope>provided</scope> </dependency> </dependencies> <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> <finalName>test</finalName> <plugins> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>8.1.10.v20130312</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webAppConfig> <contextPath>/test</contextPath> </webAppConfig> </configuration> </plugin> </plugins> </build> </project>
(1) The packaging element value is war
(2) Almost all Webs depend on servlet-api and jsp-api, but these two dependencies are provided, which means that they will not be packaged into war files in the end, because the web container will provide these two class libraries .
(3) build-finalName: used to identify the name of the main component generated by the project, and change the default value of this element to facilitate deployment.
3. Use jetty-maven-plugin for testing
Web page testing should be limited to the page level, such as JSP, CSS, JavaScript modifications, other code modifications (such as data access), please write unit tests.
The traditional web testing method requires us to compile, test, package and deploy. jetty-maven-plugin can help us save time. It can periodically check the project content and automatically update it to the built-in Jetty Web container after changes are found, that is Save us the steps of packaging and deployment. Usually, we only need to modify the source code in the IDE, and the IDE can perform automatic compilation. After the jetty-maven-plugin finds that the compiled files have changed, it will automatically update to the Jetty container, and then the Web page can be directly tested.
jetty-maven-plugin configuration
<build> <plugins> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>8.1.10.v20130312</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webAppConfig> <contextPath>/test</contextPath> </webAppConfig> </configuration> </plugin> </plugins> </build>
Notice:
(1) jetty-maven-plugin is not an official Maven plugin, you need to pay attention to groupId and artifactId; scanIntervalSeconds indicates the time interval for the plugin to scan project changes, in seconds; contextPath indicates the content path after the project is deployed. http://hostname:port/{contextPath}/
(2) By default, only the plugins under the two groupIds org.apache.maven.plugins and org.codehaus.mojo support simplified command line calls, that is, mvn help:system can be run. In order to run mvn jetty:run directly from the command line, the user needs to configure the setting.xml as follows:
<settings> <pluginGroups> <pluginGroup>org.mortbay.jetty</pluginGroup> <!-- 8、9 --> <pluginGroup>org.eclipse.jetty</pluginGroup> </pluginGroups> </settings>
If you want to use other ports, you can add the jerry.port parameter; skip the test is maven.test.skip
mvn jetty:run -Djetty.port=80 -Dmaven:test:skip=true
4. Use Cargo to automate deployment
Cargo is a set of tools to help users operate web containers, it can help users to achieve automated deployment, and it supports almost all web containers, such as Tomcat, JBoss, Jetty and Glassfish. Cargo provides Maven inheritance through the cargo-maven2-plugin, which Maven users can use to deploy web projects into web containers.
The functionality of cargo-maven2-plugin and jetty-maven-plugin look similar, but the purpose is different. jetty-maven-plugin mainly helps with daily rapid development and testing, while cargo-maven2-plugin mainly serves automated deployment.
(1) Deploy to the local web container
Cargo supports two local deployment methods, namely standalone mode and existing mode. In standalone mode, Cargo will copy a configuration from the installation directory of the web container to the directory specified by the user, and then deploy the application on this basis. Each time it is rebuilt, this directory will be emptied, and all configurations will be regenerated; existing In mode, the user needs to specify the existing web container configuration directory, and then Cargo will directly use these configurations and deploy the application to its corresponding location.
Standalone/mode deploys applications to a local web container
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.0</version>
<configuration>
<container>
<containerId>tomcat7x</containerId>
<home>D:\myspaces\worktools\apache-tomcat-7.0.37</home>
</container>
<configuration>
<!-- Standalone mode deploys the application to the local web container-->
<!--
<type>standalone</type>
<home>${project.build.directory}\tomcat7x</home>
-->
<!-- cargo.servlet.port property to modify listening port -->
<!--
<properties>
<cargo.servlet.port>80<cargo.servlet.port>
</properties>
-->
<!-- Deploy the application in existing mode to the local web container-->
<type>existing</type>
<home>D:\myspaces\WorkTools\apache-tomcat-7.0.37</home>
</configuration>
</configuration>
</plugin>
Add <pluginGroup>org.codehaus.cargo</pluginGroup> in setting.xml
Run the command: mvn cargo:start
(2) Deploy to a remote web container
First modify tomcat\conf\tomcat-users.xml to add users
<role rolename="manager-gui"/> <user username="tomcat" password="tomcat" roles="manager-gui"/>
The POM configuration is as follows
<plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.4.0</version> <configuration> <container> <containerId>tomcat7x</containerId> <type>remote</type> </container> <configuration> <type>runtime</type> <properties> <cargo.remote.username>tomcat</cargo.remote.username> <cargo.remote.password>tomcat</cargo.remote.password> <cargo.remote.manager.url>http://localhost/manager</cargo.remote.manager.url> </properties> </configuration> </configuration> </plugin>
(1) The value of the type sub-element of the remote deployment container element must be remote. Otherwise, the default value is installed, and look for the corresponding container installation directory or installation package. The installation directory or installation package is not required for remote deployment.
(2) The value of the type sub-element of configuration is runtime, which means that neither an independent container configuration nor a local existing container configuration is used, but it depends on a running one; properties declares some configurations related to container hot deployment .
(3) Run the command mvn cargo: redeploy