Web项目的目录结构
基于Java的Web应用，其标准的打包方式是WAR
一个典型的WAR文件有如下目录结构：
一个WAR包下至少包含两个子目录：META-INF和WEB-INF。
前者包含了一些打包元数据；后者是WAR包的核心，
WEB-INF下必须包含一个Web资源表述文件web.xml，
它的子目录 classes包含所有该Web项目的类，
而另一个子目录lib则包含所有该Web项目的依赖JAR包
classes和lib目录都会在运行的时候被加入到Classpath中
用户必须为Web项目显式指定打包方式为war，如：
<artifactId>account-web</artifactId> <packaging>war</packaging> <name>Maven Account-Web Project</name>
Web项目的类及资源文件：默认位置src/main/java和src/main/resources
测试类有测资源文件：默认位置src/test/java和src/test/resources
以上同一般JAR项目
不同：
Web项目还有一个Web资源目录，其默认位置是src/main/webapp
一个典型的Web项目的Maven目录结构如下：
注：finalName该元素用来标识项目生成的主构件的名称，该元素的默认值已在超级POM中设定，值为${project.artifactId}-${project.version}，如：account-web-1.0.0-SNAPSHOT.war显然，这样的名称不利于部署，我们需要配置更简洁的名字，如下：
<build>
<finalName>account</finalName>
....
</build>
使用jetty-maven-plugin进行测试可以用单元测试覆盖的代码就不应该依赖于Web页面测试
页面测试应该仅限于页面的层次，如JSP、CSS、JavaScript的修改，
其它代码修改（如数据访问），请编写单元测试
传统的Web测试方法要求我们编译、测试、打包及部署，这往往会消耗数10秒至数分钟的时间，jetty-maven-plugin能够帮助我们节省时间，它能够周期性地检查项目内容，发现变更后自动更新到内置的Jetty Web容器中。
jetty-maven-plutin默认就很好地支持了Maven的项目目录结构，配置如下：
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>8.1.9.v20130131</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webAppConfig> <contextPath>/test</contextPath> </webAppConfig> </configuration> </plugin>
scanIntervalSeconds:表示该插件扫描项目变更的时间间隔，如果不配置，默认为0，表示不扫描，用户也就失去了自动化热部署的功能
webappConfig元素下的contextPath表示项目部署后的context path。这里值为/text那么用户就可以通过
http://hostname:port/text访问该应用
配置一下settings.xml
因为默认情况下，只有org.apache.maven.plugins和org.codehaus.mojo两个groupId下的插件才支持简化的命令行调用，即可以运行mvn help:system，但mvn jetty:run就不行了，因为maven-help-plugin的groupId是org.apache.maven.plugins，而jetty-maven-plugins的groupId是org.mortbay.jetty。为了能在命令行下直接运行mvn jetty:run，用户需要配置settings.xml如下：
<!-- 可以在命令行下直接运行mvn jetty:run --> <pluginGroups> <pluginGroup>org.mortbay.jetty</pluginGroup> </pluginGroups>
命令行下启动maven-jetty-plugin
mvn jetty:run
jetty-maven-plugin会启动Jetty，并且默认监听本地的8080端口，并将当前项目部署到容器中，同时它还会根据用户配置扫描代码改动。
如果希望使用其他端口，可以添加jetty.port参数。如：
mvn jetty:run -Djetty.port=9999
可通过地址http://localhost:9999/test/测试应用了
停止用Ctrl+C
只要不是修改类名、方法名、新增加方法等较大操作，jetty-maven-plugin都能够扫描到变更并正确地将变化更新至Web容器中。
参考：jetty插件
使用Cargo实现自动化部署
Cargo通过cargo-maven2-plugin提供Maven集成，它几乎支持所有的Web容器，如Tomcat、JBoss、Jetty和Glassfish等。
jetty-maven-plugin与cargo-maven2-plugin的功能看起来很相似，但它们的目的不同，
前者主要用来帮助日常的快速开发和测试
后者主要服务于自动化部署
Cargo支持两种本地部署方式，分别为standalone模式和existing模式。
在standalone模式中，Cargo会从Web容器的安装目录复制一份配置到用户指定的目录，然后在此基础上部署应用，每次重新构建的时候，这个目录都会被清空，所有配置被重新生成。
在existing模式中，用户需要指定现有的Web容器配置目录，然后Cargo会直接使用这些配置并将应用部署到其对应的位置。
使用standalone模式部署应用至本地Web容器
<!-- 使用standalone模式部署应用至本地Web容器 -->
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.3.3</version>
<configuration>
<container>
<containerId>tomcat6</containerId>
<home>D:\tools\web\tomcat6_0_26</home>
</container>
<configuration>
<type>standalone</type>
<home>${project.build.directory}/tomcat6x</home>
</configuration>
</configuration>
</plugin>
cargo-maven2-plugin的groupId是org.codehaus.cargo，这不属于官方的两插件groupId，因此用户需要将其添加到settings.xml的pluginGroup元素中以方便命令行调用。
<!-- 可以在命令行下直接运行mvn jetty:run 和mvn cargo:start --> <pluginGroups> <pluginGroup>org.mortbay.jetty</pluginGroup> <pluginGroup>org.codehaus.cargo</pluginGroup> </pluginGroups>
type：表示部署的模式
home：表示复制窗口配置到什么位置，这里值为${project.build.directory}/tomcat6x，表示构建输出目录，即target/下的tomcat6x子目录。
container元素下的两个元素
containerId：表示容器的类型
home：表示容器的安装目录
基于该配置，Cargo会从D:\tools\web\tomcat6_0_26目录下复制配置到当前项目的target/tomcat6x/目录下
让Cargo启动Tomcat并部署应用，运行
mvn clean verify cargo:start
默认情况下，Cargo会让Web容器监听8080端口。可以通过修改Cargo的cargo.servlet.port属性来改变这一配置
更改Cargo的Servlet监听端口：
<!-- 使用standalone模式部署应用至本地Web容器 -->
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.3.3</version>
<configuration>
<container>
<containerId>tomcat6x</containerId>
<home>D:\tools\web\tomcat6_0_26</home>
</container>
<configuration>
<type>standalone</type>
<home>${project.build.directory}/tomcat6x</home>
<properties>
<cargo.servlet.port>8081</cargo.servlet.port>
</properties>
</configuration>
</configuration>
</plugin>
将应用直接部署到现有的Web容器下，需要配置Cargo使用existing模式
<!-- 使用standalone模式部署应用至本地Web容器
configuration-type:standalone
configuration-home:${project.build.directory}/tomcat6x
-->
<!-- 使用existing模式部署应用至本地Web容器
configuration-type:existing
configuration-home:D:\tools\web\tomcat6_0_26
-->
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.3.3</version>
<configuration>
<container>
<containerId>tomcat6x</containerId>
<home>D:\tools\web\tomcat6_0_26</home>
</container>
<configuration>
<type>existing</type>
<home>D:\tools\web\tomcat6_0_26</home>
</configuration>
</configuration>
</plugin>
使用existing模式部署应用至本地Web容器 基于该配置运行 mvn cargo:start 之后，便能够在Tomcat的webapps子目录看到被部署的Maven项目了。
参考：cargo插件
部署至远程Web容器
部署应用至远程Web容器
<!-- 部署应用至远程Web容器 --> <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.3.3</version> <configuration> <container> <containerId>tomcat6x</containerId> <type>remote</type> </container> <configuration> <type>runtime</type> <properties> <cargo.remote.username></cargo.remote.username> <cargo.remote.password></cargo.remote.password> <cargo.remote.manager.url>http://localhost:8080/manager</cargo.remote.manager.url> </properties> </configuration> </configuration> </plugin>
对于远程部署来说，
container元素的type子元素的值必须为remote,
默认使用installed,并寻找对应的容器安装目录或者安装包
configuration的子元素type的值为runtime，表示即不使用独立的容器配置，也不使用本地现有的容器配置，而是依赖一个已运行的窗口
properties：用来声明一些窗口热部署相关的配置。
例如：Tomcat6就需要提供用户名、密码和管理地址，
让Cargo部署应用
mvn cargo:redeploy
如果容器中已经部署了当前应用，Cargo会先将其卸载，然后再重新部署
----------------------------------------------------------------------------------------------------------------------