Maven實戰讀書筆記（13）

WAR

1、基於Java的Web應用，其標準的打包方式是WAR

2、WAR與JAR相似，不過它包含更多的內容，如JSP文件、Servlet、Java類、web.xml配置文件、依賴JAR包、靜態web資源（如HTML、CSS、JavaScript文件）等

 

一個典型的WAR文件的目錄結構

- 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

1、一個WAR包下至少包含兩個子目錄，META-INF和WEB-INF，前者包含了一些打包元數據信息，不用關心，後者是WAR包的核心，WEB-INF下必須包含一個Web資源表示文件web.xml

2、WEB-INF的子目錄classes包含全部該Web項目的類，而另外一個子目錄lib則包含全部該Web項目的依賴的JAR包，classes和lib目錄都會在運行的時候被加入到Classpath中

3、除了META-INF和WEB-INF外，通常的WAR包都會包含不少Web資源，例如你每每能夠在WAR包的根目錄下看到不少html或者jsp文件，此外，還能看到一些文件夾如img、css和js

 

顯式指定Web項目的打包方式爲war

<project>

...

       <groupId>com.juvenxu.mvnbook</groupId>

       <artifactId>sample-war</artifactId>

       <packaging>war</packaging>

       <version>1.0-SNAPSHOT</version>

...

</project>

若是不顯示指定packaging，Maven會使用默認的jar打包方式，從而致使沒法正確打包Web項目

 

一個典型的Web項目的Maven目錄結構以下

+ project

 |

 + pom.xml

 |

 + src/

  + main /

  | + java /

  | | + ServletA.java

  | | + ...

  | |

  | + resources /

  | | + config.properties

  | | + ...

  | |

  | + webapp /

  |   + WEB-INF /

  |   | + web.xml

  |   |

  |   + img /

  |   |

  |   + css /

  |   |

  |   + js /

  |   +

  |   + index.html

  |   + sample.jsp

  |

  + test /

    + java /

    + resources /

 

通常配置finalName元素，更改war包的名稱

1、該元素默認值已在超級的POM中設定，值爲 $ {project.artifactId}-$ {project.version}

2、不過上面這樣的名稱顯然不利於部署

3、配置<finalName>account</finalName>，項目生成的war包名稱就會成爲account.war，方便部署

 

關於Web測試

1、通常方式，將war包部署到應用服務器，而後打開瀏覽器進行測試，好比驗證程序功能、驗證頁面佈局，尤爲是一些與頁面相關的的特性

2、近年來也出現了不少自動化的Web測試技術如Selenium，它可以錄製Web操做，生成各類語言腳本，而後自動重複這些操做以進行測試，這類技術方法是將來的趨勢，可是仍是沒法徹底替代，手動的、親眼對比的驗證的測試

 

關於Web頁面測試和底層代碼測試的一些建議

1、在介紹jetty-maven-plugin以前，要強調一點，雖然手動的Web頁面測試是必不可少的，但這種方法毫不應該被濫用

2、現實中常見的狀況是，不少程序員即便修改了一些較爲底層的代碼 (如數據庫訪問、業務邏輯)，都會習慣性地打開瀏覽器測試整個應用，這每每是沒有必要的

3、能夠用單元測試覆蓋的代碼就不該該依賴於Web頁面測試，且不說頁面測試更加耗時耗力，這種方式還沒法自動化，更別提重複性了

4、所以Web頁面測試應該僅限於頁面的層次，例如JSP、CSS、JavaScript的修改，其餘代碼修改 （如數據訪問），請編寫單元測試

 

爲何使用jetty-maven-plugin這個插件幫助測試？

1、傳統的Web測試方法要求咱們編譯、測試、打包及部署，這每每會消耗數10秒至數分鐘的時間，jetty-maven-plugin可以幫助咱們節省時間，它可以週期性地檢查項目內容，發現變動後自動更新到內置的Jetty Web容器

2、換句話說，它幫咱們省去了打包和部署的步驟，jetty-maven-plugin默認就很好地支持了Maven的項目目錄結構，在一般狀況下，咱們只須要直接在IDE中修改源碼，IDE就可以執行自動編譯，jetty-maven-plugin發現編譯後的文件變化後，自動將其更新到Jetty容器，這時就能夠直接測試Web頁面了

 

配置jetty-maven-plugin

<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>

對上述配置進行解釋

1、jetty-maven-plugin並非官方的Maven插件，它的groupId是org.mortbay.jetty

2、使用了Jetty 7的最新版本，在該插件的配置中，scanIntervalSeconds顧名思義表示該插件掃描項目變動的時間間隔，這裏的配置是每隔10秒

3、須要注意的是，若是不進行配置，該元素的默認值是0，表示不掃描，用戶也就失去了所謂的自動化熱部署的功能

4、webappConfig元素下的contextPath表示項目部署後的context path，例如這裏的值爲/test，那麼用戶就能夠經過http://hostname:port/test/訪問該應用

 

配置jetty-maven-plugin插件的命令行簡化操做

默認狀況下，只有org.apache.maven.plugins和org.codehaus.mojo兩個groupId下的插件才支持簡化的命令行調用，便可以運行mvn help:system，但mvn jetty:run就不行了

這是由於，maven-help-plugin是groupId是org.apache.maven.plugins，而jetty-maven-plugin的groupId是org.mortbay.jetty，爲了直接能在命令行直接運行mvn jetty:run，用戶須要配置settings.xml：

<settings>

       <pluginGroups>

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

       </pluginGroups>
</settings>

 

啓動Jetty

命令mvn jetty:run

jetty-maven-plugin會啓動Jetty，而且默認監聽本地的8080端口，並將當前項目部署到容器中，同時它還會根據用戶配置掃描代碼改動

 

若是但願使用其餘端口，運行jetty

能夠添加jetty.port參數

mvn jetty:run -Djetty.port=9999

 

關於jetty-maven-plugin插件自動掃描的說明

啓動jetty後，用戶能夠在IDE中修改各種文件，如JSP、HTML、CSS、JavaScript甚至是Java類。只要不是修改類名、方法名等較大的操做，jetty-maven-plugin都可以掃描到變動並正確地將變化更新至Web容器中

 

jetty-maven-plugin插件的進一步研究

1、熱部署僅僅是jetty-maven-plugin插件最核心的配置點

2、還能夠自定義web.xml的位置、項目class文件的位置、web資源目錄的位置等

3、用戶還可以以WAR包的方式部署項目，而後執行一些集成測試，最後中止容器

4、進一步研究地址，http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin

 

使用Cargo實現自動化部署，Cargo是什麼？

Cargo是一組幫助用戶操做Web容器的工具，它可以幫助用戶實現自動化部署，並且它幾乎支持全部的Web容器，如Tomcat、JBoss、Jetty和Glassfish等。

Gargo經過cargo-maven2-plugin提供了Maven集成，Maven用戶可使用該插件將Web項目部署到Web容器中

 

cargo-maven2-plugin和jetty-maven-plugin的區別

雖然cargo-maven2-plugin和jetty-maven-plugin的功能看起來很類似，但它們的目的是不一樣的

1、jetty-maven-plugin主要用來幫助平常的快速開發和測試

2、cargo-maven2-plugin主要服務於自動化部署

 

Cargo的部署

Cargo支持兩種本地部署的方式，分別爲standalone模式和existing模式

1、standalone模式中，Cargo會從Web容器的安裝目錄複製一份配置到用戶指定的目錄，而後在此基礎上部署應用，每次從新構建的時候，這個目錄都會被清空，全部配置被從新生成

2、而在existing模式中，用戶須要指定現有的Web容器配置目錄，而後Cargo會直接使用這些配置並將應用部署到其對應的位置

 

使用standalone模式部署應用至本地Web容器(tomcat6x)
<plugin>

       <groupId>org.codehaus.cargo</groupId>

       <artifactId>cargo-maven2-plugin</artifactId>

       <version>1.0</version>

       <configuration>

              <container>

                     <containerId>tomcat6x</containerId>

                     <home>D:\cmd\apache-tomcat-6.0.29</home>

              </container>

              <configuration>

                     <type>standalone</type>

                     <home>${project.build.directory}/tomcat6x</home>

              </configuration>

       </configuration>

</plugin>

對上面的配置進行解釋：

1、cargo-maven2-plugin是groupId是org.codehaus.cargo，這不屬於官方的兩個Maven插件groupId，所以用戶須要將其添加到settings.xml的pluginGroup元素中以方便命令行調用

2、cargo-maven2-plugin包括了container和configuration兩個元素，configuration的子元素type表示部署的模式（這裏是standalone）configuration的子元素home表示複製容器配置到什麼位置，這裏的值爲${project.build.directory}/tomcat6x，表示構件輸出目錄，即target/下的tomcat6x子目錄

3、container元素下的containerId表示容器的類型，home元素表示容器的安裝目錄

4、基於該配置Cargo會從D:\cmd\apache-tomcat-6.0.29目錄下複製配置到當前項目的target/tomcat6x/目錄下

5、執行mvn cargo:start，讓Cargo啓動Tomcat並部署應用

 

Cargo會讓Web容器監聽8080端口，如何修改端口號爲8081

<plugin>

       <groupId>org.codehaus.cargo</groupId>

       <artifactId>cargo-maven2-plugin</artifactId>

       <version>1.0</version>

       <configuration>

              <container>

                     <containerId>tomcat6x</containerId>

                     <home>D:\cmd\apache-tomcat-6.0.29</home>

              </container>

              <configuration>

                     <type>standalone</type>

                     <home>${project.build.directory}/tomcat6x</home>

                     <properties>

                            <cargo.servlet.port>8081</cargo.servlet.port>

                     </properties>

              </configuration>

       </configuration>

</plugin>

 

使用existing模式部署應用至本地Web容器

<plugin>

       <groupId>org.codehaus.cargo</groupId>

       <artifactId>cargo-maven2-plugin</artifactId>

       <version>1.0</version>

       <configuration>

              <container>

                     <containerId>tomcat6x</containerId>

                     <home>D:\cmd\apache-tomcat-6.0.29</home>

              </container>

              <configuration>

                     <type>existing</type>

                     <home> D:\cmd\apache-tomcat-6.0.29</home>

              </configuration>

       </configuration>

</plugin>

 

部署至遠程Web容器？沒測出來，他媽的。