Maven Learning Note (10): Building a web App with Maven

in practice, most of the applications we create are Web applications. In the world of Java, the standard way to package Web projects is war. In this chapter, we describe how to build a Web app using Maven, and we'll show you how to use Jetty-maven-plugin to quickly develop and test Web tests, and use cargo to automate deployment of Web projects. the directory structure of the Web project      Java-based Web applications, the standard way of packaging is war. A war is similar to a jar, but he can include more content, such as JSP files, Servlets, Java classes, Web. XML configuration files, dependent jar packages, and static website resources such as HTML, CSS, JavaScript files, and so on. A typical war file would have the following directory structure:-war/     +META-INF/     +WEB-INF/     | + classes/     | | + servleta.class     | | + config.properties     | | + ...     | |     | + lib/     | | + dom4j-1.4.1.jar     | | + mail-1.4.1.jar     | | + ...     | |     | + web.xml     |     + img/     |     +css/      |     + js/     |     + index.html     + sample.jsp  &nbs P   A war package contains at least two sub-items: Meta-inf and Web-inf. The former contains some packaging metadata information, generally do not care, and the latter is the core of the war package. Web-inf must contain a Web resource description file, XML, whose subdirectory classes contains all of the Web project's classes, while the other subdirectory Lib contains all the dependent jar packages for that Web project, and the classes and LIB directoriesWill be added to the classpath at run time. In addition to Meta-inf and Web-inf, a generic war package will contain many Web resources.      maven the way the Web project is packaged must appear to be specified as a war, otherwise it cannot be packaged correctly. Such as:

<project     > ... <groupId>com.javenxu.mvnbook</goupId> <artifactId>sample-war</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> ...</project> 

      The MAVEN directory structure for a typical Web project is as follows: + project          |     + pom.xml     |     + src/          + main/      &NB Sp   | + Java/          | | + servleta.java          | | + ...          | |          | + Resources/          | | + ...          | |          | + webapp/          |   + web-inf/                |   | + web.xml          |   |          |   + img/          |   |          |   + CSS/          |   |         |   + JS/          |   +           |   +index.html                           /    |   +sample.jsp          |          + test/      &NBS P   | + Java/          | + Resources/      under the src/main/webapp/directory, you must include a subdirectory web-inf, which must also contain the Web. xml file. Other files and directories in the Src/main/webapp directory include HTML, JSP, CSS, JavaScript, and so on, which are exactly the same as the Web resources in the war package.                      
<finalname>:In some Web projects, you might see the configuration of the finalname element. The element is used to identify the name of the main artifact generated by the project, the default value of which is set in the Super Pom, and the value is ${project.artifactid}-${project.version}, but the name is too verbose, We don't want to enter a lengthy address when we visit the page, so we'll need a more concise name for the war package. example, you can configure the Finalname element as follows: <finalName>account</finalName>With this configuration, the war package name generated by the project becomes Account.war, making it easier to deploy.
to test with Jetty-maven-plugin:Traditional Web testing methods require us to compile, test, package, and deploy, which often consumes a few 10 seconds to a few minutes, Jetty-maven-plugin can help us save time, it can periodically check the contents of the project, find the changes automatically updated to the built-in jetty The Web container. In other words, it saves us the steps to package and deploy. Jetty-maven-plugin supports MAVEN's project directory structure by default.     In general, we only need to directly in the IDE to modify the source code, the IDE can perform automatic compilation, Jetty-maven-plugin found after the compiled file changes, automatically update it to the jetty container, then you can directly test the Web page. Using Jetty-maven-plugin is easy. Specify the coordinates of the plug-in, and configure it slightly, with the following code:

<plugin>     <groupId>org.mortbay.jetty</groupId>     <artifactid>jetty-maven-plugin </artifactId>     <version>7.1.6.v20100715</version>     <configuration>          < scanintervalseconds>10</scanintervalseconds>                <webAppConfig>               <contextpath>/test </contextPath>          </webAppConfig>     </configuration></plugin>

In the configuration of the plug-in, scanintervalseconds as the name implies that the plug-in scans the time interval for project changes, where the configuration is every 10 seconds. It is important to note that if you do not configure the default value of this element is 0, which means that the user will lose the functionality of the so-called automated thermal deployment without scanning. The contextpath under the Webappconfig element in the preceding code represents the context path after the project is deployed.     For example, the value here is/test, so the user can access the app through Http://hostname:port/test. Next, start Jetty-maven-plugin. Before that, you need to make a minor change to settings.xml. As described earlier, by default, only plug-ins under the Org.apache.maven.plugins and Org.codehaus.mojo two groupid support simplified command-line invocation, that is, you can run MVN Help:system, but MVN jetty : Run won't be. Because Jetty-maven-plugin's GroupID is Org.mortbay,jetty, in order to be able to run MVN Jetty:run directly on the command line, the user needs to configure Setting.xml as follows:

<settings>     <pluginGroups>          <pluginGroup>org.mortbay.jetty</pluginGroup>      </pluginGroups>     ...</settings>

You can now start Jetty-maven-plugin by running the following command: $MVN Jetty:runJetty-maven-plugin starts the jetty and listens to the local 8080 port by default and deploys the current project to the container, while also scanning for code changes based on user configuration. If you want to use a different port, you can add the Jetty.port parameter. For example: $MVN jetty:run-djetty.port=9999You can now open the http://localhost:9999/test/test app.               To stop jetty, simply enter CTRL + C at the command line. After you start jetty, users can modify various types of files in the IDE. As long as it is not a large operation such as modifying the class name, the method name, Jetty-maven-plugin can scan to change and update the changes correctly to the Web container.
use cargo for automated deployment: deploy to the local Web container:          cargo helps users automate the deployment of Web projects on Web containers, which supports almost all web containers. The cargo provides MAVEN integration through Cargo-maven2-plugin. Although the functions of cargo-maven2-plugin and Jetty-maven-plugin look very similar, their purpose is different, jetty-maven-plugin is mainly used to help the daily rapid development and testing, Cargo-maven2 primarily serves the automation deployment. The      cargo supports two local deployment modes, standalone mode and existing mode, respectively. In standalone mode, cargo copies a copy of the configuration to the user-specified directory from the Web container's installation directory, and then deploys the application on top of it, which is emptied every time the rebuild is built, and all configurations are regenerated. In existing mode, the user needs to specify the existing Web container configuration directory, and cargo will use the configuration directly and deploy it to its appropriate location.       The following code shows a sample configuration of the standalone mode.

<plugin     > <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.0</version> <configuration> <container> <containerid> ;tomcat6x</containerid> 
By default, cargo will allow the Web container to listen on port 8080, which we modified with the cargo Cargo.servlet.port property to change this configuration.     Cargo-maven2-plugin's GroupID is Org.codehaus.cargo, which is not part of the official two Maven plugin GroupID, so the user needs to add it to Setting.xml's plugingroup element for easy command-line invocation. Now, to get cargo to start Tomcat and deploy the app, just run:$MVN Cargo:startThen we have access to the Web project's page. To deploy the app directly under an existing Web container, you need to configure cargo to use existing mode, as follows:
<plugin>     <groupId>org.codehaus.cargo</groupId>     <artifactid>cargo-maven2-plugin </artifactId>     <version>1.0</version>     <configuration>          <container>               <containerId>tomcat6x</containerId>               

deploy to a remote Web container:In addition to having cargo manage the local Web container directly and then deploy the app, you can also have the cargo deployment applied to a remote, running Web container. The assumption is that you have the appropriate administrator permissions for the container.
<plugin> <groupId>org.codehaus.cargo</groupId> <artifactid>cargo-maven2-plugin</ artifactid> <version>1.0</version> <configuration> <container> &          Lt;containerid>tomcat6x</containerid> For remote deployment, the value of the type child element of the container element must be remote. The type child element value of the configuration is runtime, which means that neither a stand-alone container configuration nor a local existing container configuration is used, but rather relies on a running container. The properties element is used to declare some container thermal deployment-related configurations. For example, TOMCAT6 here will need to provide a username, password, and administrative address.     It is important to note that this configuration is inconsistent for all containers, and the reader needs to consult the corresponding cargo documentation. With the above configuration, you can have cargo deploy the application. Run the command as follows:$MVN Cargo:redeploy
Maven Learning Note (10): Building a web App with Maven