jinfeng_wang

Written by Srikanth Shenoy November 2003

Translated by jinfeng wang 2005年三月

原文地址：http://www.theserverside.com/articles/article.tss?l=MavenMagic

本文的翻譯已經原作者同意，轉載請保持原文。如有問題和意見可以和原作者或我聯系。
Part 2 : http://www.tkk7.com/jinfeng_wang/archive/2005/03/14/2074.html
Part 3 : http://www.tkk7.com/jinfeng_wang/archive/2005/03/15/2089.html

Introduction(簡介)

Maven is a high-level, intelligent project management, build and deployment tool from the Apache project. There is nothing that Maven does that Ant cannot do. Ant gives the ultimate power and flexibility in build and deployment to the developer. Why do you need Maven then? Maven adds a layer of abstraction above Ant (and uses Jelly). Maven can be used to build any Java application, but in this article we will investigate the applicability of Maven from a J2EE standpoint. J2EE build and deployment as we know it today is pretty much standardized. Every enterprise has some variations, but in general it is all the same: deploying EARs, WARs, and EJB-JARs. Maven captures this intelligence and lets you achieve the build and deployment in about 5-6 lines of Maven script compared to dozens of lines in an Ant build script. In other words, Maven simplifies a developer's life. Everybody loves things to be simple right?

Maven是Apache的高度智能的項目管理、構建、部署工具，它能做Ant所有能做的事情。Ant給開發者在構建部署過程中提供了極強的火力和靈活性，那么為何你還會選擇Maven呢？Maven在Ant的基礎上（利用Jelly）提供了一個中間抽象層。Maven可以用了build任何Java應用，但在這篇文章中我們只針對J2EE細談Maven的適用性。正如我們已熟知的，目前J2EE的構建部署過程已經相當的標準化，雖然各企業應用之間可能仍存在著一定的區別，但總的來說它們的build、deploy過程幾乎都是相同的：部署R、WAR、EJB JAR。Maven正是抓住了這其中的相同性，用戶用5～6行的Maven腳本就完成build、deploy過程,而完成相同的任務Ant腳本則需要許多行。換句話說，Maven簡化了開發者的工作，每個人都喜歡工作被簡化，不是么？

If you think of Ant as a modular language like C, then Maven can be compared to an object oriented language like C++ or Java. Maven plugins are like the standard JDK libraries. The C language, albeit a giant leap from assembly languages, falls short of addressing the complexities of enterprise projects. Java on the other hand, being object oriented, forces the developer to program in a certain way and reduces complexities in large enterprise projects by letting you manage dependencies by breaking them into chunks via CRC - Class, Responsibility and Collaboration - which is a big paradigm shift from C. There are some tasks that C alone can do, but for the majority of enterprise programming Java will suffice.

如果把Ant比作模塊化語言（例如C），那么就可以把Maven比作面向對象語言（例如C++、Java），Maven的插件（plug-in）則扮演著標準JDK庫的角色。C語言雖然大大超越了匯編語言，但還是陷入了企業項目復雜性的泥潭。而作為面向對象語言的Java,強制開發者按照一定的思路進行開發，使用CRC（Class, Responsibility和Collaboration）將企業應用中的聯系進行分解（這是由C轉移來的新的編程范型），便于開發者掌握它們之間的依賴關系，減少大型企業項目中的復雜性。雖然某些任務仍然還是必須使用C才能完成，但對于絕大部分企業編程使用Java足夠了。

Every comparison between C and Java listed above applies to Ant and Maven. Ant lets you do any variations you want, but requires a lot of scripting. Maven on the other hand mandates certain directories and file names, but it provides plugins to make life easier. The restriction imposed by Maven is that only one artifact is generated per project (A project in Maven terminology is a folder with a project.xml file in it). If you are thinking "My EAR artifact itself consists of multiple artifacts, I am out of luck, I cannot use Maven", it is time to take a closer look. A Maven project can have sub projects. Each sub project can build its own artifact. The topmost project can aggregate the artifacts into a larger one. This is synonymous to jars and WARs put together to form an EAR. Maven also provides inheritance in projects. I will address these topics in the following sections. At the end of this article you will be able to build J2EE project artifacts using Maven.

上面對于C和Java的比較完全可以適用于Ant和Maven，Ant讓你可以做任何的事情，但是需要許多的腳本，而另一方面Maven會強制你使用一定的目錄和文件名，但是Maven提供了許多的插件，讓你的工作變得相當簡單。Maven給項目所加的限制就是“每個項目（在Maven中一個項目是指帶有project.xml的一個文件夾）只能生成一個制品（artifact）”。如果你覺得“我的EAR中包含多個制品，很不幸，我無法使用Maven”，那就請繼續往后看吧。一個Maven項目可以由子項目，每個子項目可以build生成自己的制品，最頂層的項目可以將子項目的制品打包生成一個大的包。Maven在項目之間還提供了繼承（inheritance），這將在隨后講述。在文章的最后，將會教你如何使用Maven構建J2EE項目。

Maven simplifies build enormously by imposing certain fixed file names and acceptable restrictions like one artifact per project. Maven給項目加上了一定的限制，例如項目的文件名、每個項目只能生成一個制品等，大大簡化了構建過程。

First there was make. But make was not cross platform. Then came Ant. Ant lets you do cross-platform builds in a systematic manner. It is very elegant compared to make. However as you may have already realized, build tasks in a project are pretty standard. The tricky part is partitioning, compiling and packaging classes, resources and descriptors into the right deployment artifacts like jars, WARs and EARs and managing dependencies on the right version of libraries - both internal and third party ones. After a while you will find yourself copying Ant script snippets from one place to another and modifying them. Then there is the universal problem of classpath. We all have different versions of different libraries installed in different locations on the development workstations. Nobody can be sure if the Ant build copied the right version of the library into the deployment artifact at all. We all have seen the classic developer shrug - "It works on my machine"! Ant does little to address this problem. Enter Maven.

首先是Make，但是Make不是跨平臺的。隨后產生了Ant,它運行你能夠以一種更加系統化的方式進行跨平臺build。與Make相比，Ant變得優雅多了，但正如你已經意識到的，在項目中的build是相當標準的過程。最好的方式就是將項目進行分解，編譯，將class、資源和描述符打包成jar、WAR、EAR，管理各版本正確的庫（包括內部庫和第三方庫）之間的依賴關系。你會發現自己經常的將Ant的腳本到處拷貝，經常的classpath問題也就隨之出現了。在我們的開發平臺中在許多地方安裝了各種版本各異的庫。你根本無法確定Ant在build、deploy制品時，拷貝的是否是版本正確的庫。我們會經?？吹介_發者聳肩搖頭的經典鏡頭，“它在我機器上是好的啊”!Ant對于此問題毫無辦法，那就進入Maven的世界吧。

What is it that makes Maven an attractive option for today's enterprises? The basic tenet of Ant build scripts is copying, renaming and deleting files under various conditions into various deployable artifacts - which are again treated as files on your computer by the build script. Maven hides the fact that everything is a file and forces you to think and script to create a deployable artifact such as an EAR, that has a dependency on a particular version of a third party library residing in a shared remote (or local) enterprise repository, and then publish your library into the repository as well for others to use. No more classpath issues. No more mismatch in libraries. This sounds like a very real and practical solution to our everyday problems. It also gives you the power to embed Ant scripts within Maven scripts if absolutely essential.

那么是什么讓Maven變成一個如此具有吸引力的選擇呢？Ant腳本的基本原則就是在各種情況下拷貝、改名和刪除文件，生成可部署制品，而Ant腳本又將這些制品看作是機器中的文件,再對它進行拷貝、改名和刪除……，不斷重復以上過程。Maven則隱藏了一切都是文件的事實，強制你按照特定的方式思考、編寫腳本，創建依賴于特定版本的第三方庫的可部署制品（例如EAR），而這些庫則存放在共享遠程（或本地）企業倉庫（repository）中，然后將你自己開發的庫發布到倉庫中供別人使用，再也沒有了classpath問題，再也不會出現庫版本不一致的問題。Maven真實有效的解決了之前我們每天都面對的問題。此外，Maven也提供了在必要情況下將Ant腳本嵌入到Maven腳本中的功能。

In the words of Jason van Zyl, an important contributor to the Maven source code base, "the intent of Maven is to make intra-project development highly manageable in the hopes of providing more time for cross-project development. You might call it cross-project pollination or the sharing of project development knowledge; this is what Maven attempts to encourage".

用Jason van Zyl（Maven源代碼的重要貢獻者）的話說，“Maven的目的就是使項目內部開發變得高度可控，進一步的目標是能為跨項目的開發節余更多的時間。你可以稱之為跨項目授粉，或者共享項目開發知識，而這恰是Maven所鼓勵的?！?/SPAN>

Maven installation (Maven安裝)

You can download the 1.0 Release Candidate from http://maven.apache.org/builds/release/1.0-rc1/.

The version of Maven available at the time of this writing was 1.0-beta 10. Everything in this article refers to the 1.0-beta 10. It is feature complete for 1.0 pending any defects. Unzip the archive onto your machine. It creates a directory called maven-1.0-beta-10. Before you go any further, set the MAVEN_HOME environment variable to this directory. Also add the MAVEN_HOME/bin to the PATH environment variable. Make sure you have set the JAVA_HOME appropriately. Go to the command line and type maven -g. If you see a long list of output, your installation has succeeded.

你可以從http://maven.apache.org/builds/release/1.0-rc1/ 下載1.0 Release版。

在寫這篇文章的時候，Maven的當前版本是1.0-beta 10。因此這篇文章中的所有內容都是指1.0-beta 10。此版本已提供了所有的特性、修補了所有缺陷。將壓縮包在你機器解壓，它將創建名為maven-1.0-beta-10的目錄。在做其他之前，請創建環境變量MAVEN_HOME，并設值為此目錄。然后將MAVEN_HOME/bin添加到環境變量Path中。確認你已經正確設置了JAVA_HOME。然后轉到命令行方式下，鍵入“maven -g”命令。如果成功看到一系列的輸出，那么就說明安裝成功。

Maven basics (Maven基礎)

The basic concept of Maven is a project. In Maven terms, any directory that has a project.xml in it is a project. When the sub-directories underneath have their own project.xml, they are projects on their own too. Another concept in Maven is that of a repository. The repository holds the artifacts on which your project depends. There are two kinds of repository: local and remote. Both of them can be declaratively set. Unless specified otherwise, the local repository is created in a special directory called ".maven/repository". In Windows, this directory is created in C:\Documents And Settings. For example, if your project depends on commons-logging version 1.0.2, you can specify the dependency in project.xml and when maven is executed, it will copy the appropriate commons-logging jar file from the remote repository to the local repository and then use it to build your project's artifact. The maven repository folder has subfolders for each library. For instance, there is a sub folder for commons-logging. Beneath the commons-logging folder there is another subfolder called jars. This jars folder has the commons logging jar files suffixed by version number. Jars are not the only type of artifacts supported in the repository. You can have EARs and WARs too.

Maven的基本概念就是Project,在Maven里面，每個目錄包含有project.xml的目錄都是一個Project。如果子目錄中含有project.xml，那么他們自己就是project。在Maven中的另外一個概念就是倉庫（repository）。倉庫用于保存項目所使用的所有的制品。Maven有兩種倉庫：本地倉庫和遠程倉庫。它們都可以用聲明的方式進行配置。除非特別聲明，本地倉庫的位置一邊在“.maven/repository”目錄。在Windows中，該目錄在C:\Documents And Settings。例如，如果你的項目使用了commons-logging的1.0.2版本，那么你可以在project.xml中進行聲明，當運行maven命令是，它將會從遠程倉庫中拷貝正確的commons-logging的jar文件到本地倉庫，然后構建你的項目，生成制品。Maven倉庫為每個庫創建生成一個子目錄。例如，它將會為commons-logging創建一個子目錄。在commons-logging文件夾中，會含有一個名為jars的子目錄。在jars文件夾中，將會存放含有相應版本號為后綴的jar文件。在Maven倉庫中，它所能夠支持的制品不僅僅是jar,還有EAR和WAR等。

The role of the repository is immediately obvious. Instead of each project having its own copies of third party libraries, the repository helps developers across projects to share the libraries. Each project can also in turn generate its artifacts and publish it into the remote repository. The process of publishing a jar into the repository is called "install" in Maven lingo. This install process helps organizations to share internal artifacts across projects in a standard manner. This also holds the basis for continuous integration among inter-dependent projects. Continuous Integration is a concept that was developed by Martin Fowler and developers of Cruise Control. Individual projects can continue to build and publish the release and snapshot artifacts to corporate repositories. Daemon processes running on dedicated machines can schedule integration builds, deploy to execution platforms (application servers) and run automated tests to verify the build status. Figure 1 shows the role of project.xml, repository, goals and plugins in Maven build. The grey colored rectangles are provided by you. The green colored rectangles are provided by Maven. The pink colored rectangle shaded is the output - the deployment artifacts from your project. Custom plugins and maven.xml are optional. The rest of the inputs are mandatory.

倉庫的角色是相當明顯的，每個項目不再需要各自包含自己所依賴的第三方庫，倉庫將會幫助開發者在多個項目間共享庫。反過來，每個項目也可以自己build制品，然后deploy到遠程倉庫中。按照Maven的術語，往倉庫中發布jar的過程被稱為“安裝（install）”。安裝過程可以幫助開發者用一種標準的方式在項目間共享內部制品。這也就是相互依賴的項目間持續集成（continuous integration）的基礎。持續集成是由Martin Fowler提出的概念，他還開發了Cruise Control工具。項目可以連續的build，最新release或snapshot制品可連續的發布到公司倉庫中。在專門機器運行的守護進程（daemon process）將會定時的持續構建、發布制品到應用服務器中、進行自動測試并檢驗build狀態。圖1展示了在Maven構建過程中project.xml、倉庫、goal、plug-in各自的角色?；疑娇虻膬热輰⒂赡闾峁?，綠色方框的內容則由Maven提供，粉紅色方框的內容則用于輸出―項目生成的部署制品。其中定制的plug-in和maven.xml則是可選的，而其他輸入部分則必須的。

Figure 1 Overview of Maven build elements

圖1 Maven構建元素總覽

project.xml details (project.xml細述)

The project.xml is divided into four main parts namely, Project Management Section, Project Dependency Section, Project Build Section and Project Reports Section. Listing 1 shows the outline of a typical project.xml. The mandatory items are shown in bold.

整個project.xml被分為四個部分：項目管理部分、項目依賴部分、項目構建部分、項目報告部分。在表1中給出了典型project.xml的概要，其中必需項使用粗體顯示。

Listing 1 Outline of project.xml

01 <?xml version="1.0"?>
02 <project>
03   <pomVersion>3</pomVersion>
04   <groupId>Sample-Maven-Project</groupId>
05   <id>sample-project</id>
06   <currentVersion>1.1</currentVersion>
07   <name>Sample Maven Project</name>
08
09   <!--         Project Management section  goes here        -->
10
11   <!--         Project Dependency section  goes here        -->
12
13   <!--            Project Build section goes here           -->
14
15   <!--           Project Reports section goes here          -->
16
17 </project>

• Line 02 - Root element defining the project.
• Line 03 - Project Object Model (POM) Version. This tag is unused but needed.
• Line 04 - A directory with this name is created in Maven repository to hold the artifacts of projects sharing the group id.
• Line 05, 06 - The id and version is used to create the artifact name as -.jar
• Line 07 - Name of the Project

表1 project.xml概要

  01 <?xml version="1.0"?>
02 <project>
03   <pomVersion>3</pomVersion>
04   <groupId>Sample-Maven-Project</groupId>
05   <id>sample-project</id>
06   <currentVersion>1.1</currentVersion>
07   <name>Sample Maven Project</name>
08
09   <!--         項目管理部分        -->
10
11    <!--         項目依賴部分        -->
12
13  <!--         項目構建部分          -->
14
15  <!--         項目報告部分         -->
16
17 </project>

第2行：義項目的根元素。

• 第3行：Project Object Model (POM)版本，此tag雖然無用，但卻是必需的。
• 第4行：在Maven倉庫中將會創建一個用此命名的目錄，所有相同groupId的項目生成的制品都存放于此目錄。
• 第5，6行：id和version，用于做為生成制品的文件名，-.jar。
• 第7行項目名。

The Project Management Section is shown in detail in Listing 2 and has general information on the organization, its web site, project web site, location of SCM, deployment and issue tracking site, developer list, mailing lists to name a few. Most of the items in this section is boilerplate and are optional. Maven allows inheritance in the project.xml. Every organization can have an enterprise wide template which can be extended for projects. Each subproject will simply fill in the relevant section of this file. Most of the project management section elements get defined in the enterprise wide template and top-level project template. The only mandatory element is the organization name.

在表2中詳細列出項目管理部分的內容，它包含的信息有：開發組織、開發組織網站、項目站點，SCM地點、發布以及問題跟蹤站點、開發者列表、郵件列表等。在項目管理部分的絕大部分item都可以作為模板使用，并且它們大都是可選的。Maven支持在project.xml中繼承。每一個開發組織都可以擁有一個企業范圍內的模板，供各項目使用。每一個子項目只需要填寫相應部分project.xml中的部分內容即可，項目管理部分的信息已經在企業范圍的模板或者在最頂層項目模板中進行了定義。這里開發組織名（organization name）是必需的。

Listing 2 Project Management Section in project.xml

01   <organization>
02      <name>Foobar Travelsname>
03      <url>http://www.foobar.comurl>
04      <logo>http://www.foobar.com/logo.jpglogo>
05   organization>
06
07   <inceptionYear>2003inceptionYear>
08   <package>foobar.blah.*package>
09   <logo>http://www.foobar.com/project-logo.jpglogo>          |
10   <description>Project description goes heredescription>
11   <shortDescription>Short DescriptionshortDescription>
12   <url>http://www.foobar.comurl>
13   <issueTrackingUrl>http://jira.foobar.comissueTrackingUrl>
14   <siteAddress>http://staging.foobar.comsiteAddress>
15   <siteDirectory>/etc/stagingsiteDirectory>
16   <distributionDirectory>/etc/buildsdistributionDirectory>
17
18   <repository>
19      <connection>cvs:pserver:anon@foobar.com:/fooconnection>
20      <url>http://scm.foobar.comurl>
21   repository>
22
23   <mailingLists>
24      <mailingList>
25         <name>Dev Listname>
26         <subscribe>subscribe-dev@foobar.comsubscribe>
27         <unsubscribe>unsubscribe-dev@foobar.comunsubscribe>
28      mailingList>
29      
30      
31   mailingLists>
32
33   <developers>
34      <developer>
35         <name>Srikanth Shenoyname>
36         <id>shenoyid>
37         <email>srikanth@srikanth.orgemail>
38      developer>
39      
40      
41   developers>

Lines 01-05 - Organization details

• Line 08 - Top level package for the project
• Line 09 - Project Logo
• Line 12 - Project web site
• Line 14 - The site where the project is hosted
• Line 15 - Physical location of project deployment
• Line 16 - Physical location where the project distributions are available
• Lines 18-21 - SCM to access the project source
• Lines 23-31 - Mailing list for the project
• Lines 33-41 - Developers in the project
• 第1~5行：開發組組織描述。
• 第8行：項目的最頂層包
• 第9行：項目logo
• 第12行：項目的網址
• 第14行：項目的發布網址
• 第15行：項目部署的物理位置
• 第16行：項目的發行地址
• 第18～21行：項目源代碼的SCM位置
• 第23～31行：項目的郵件列表
• 第33～41行－項目的開發者

Figure 2 Sample Maven Project Organization

圖2 Maven項目組織舉例

The Project Build Section describes the location of source, test and resource files. This section is generally defined at the organization level to standardize templates for all projects in the organization, or at the main project level to standardize the templates for all underlying sub projects respectively. Listing 3 shows the project build section. All the information about project organization shown in Figure 2 is defined here. The project organization can be changed and so can the project.xml. All the elements in this section are optional. However, note that if this section is not specified, no build ever gets done. Once the build is complete, Maven automatically runs the tests specified in the unit test section.

項目構建部分具體描述了源代碼、測試代碼、和資源文件的位置。此部分可以在組織級別進行定義，對整個組織內的所有項目采用統一的模板；也可以由主項目進行定義，對其下面的所有子項目采用標準化模板。表3中給出了項目構建部分的樣例。所有在圖2中的項目組織信息都在此部分定義。當然，項目的具體組織結構和project.xml是可以根據各自情況進行修改的，這部分中的所有內容都是可選的。但是注意，如果整個項目構建部分沒用任何的內容，那么就有任何的項目build動作。一旦項目build完畢，Maven就會自動運行在單元測試（unit test）中描述的測試。

Listing 3 Project Build Section in project.xml

表3  project.xml中的項目構建部分

01 <build>
02   <nagEmailAddress>srikanth@srikanth.orgnagEmailAddress>
03   <sourceDirectory>${basedir}/src/javasourceDirectory>
04   <unitTestSourceDirectory>${basedir}/test/javaunitTestSourceDirectory>
05   <unitTest>
06      <includes>
07         <include>**/*Test.javainclude>
08      includes>
09   unitTest>
10
11   <resources>
12      <resource>
13         <directory>${basedir}/src/confdirectory>
14         <includes>
15            <include>*.propertiesinclude>
16         includes>
17      resource>
18   resources>
19 build>

• Line 02 - Email address to send notification about the build status
• Line 03 - Folder containing the source files for the project. The source can be java, jsp and so on.
• Line 04 - Directory containing the unit test files for the project.
• Lines 05-09 - The test file name pattern to run after the build is completed
• Lines 11-19 - Resources to be copied in case a jar is created.
• 第2行：用于發送“build status”通知的Email地址
• 第3行：項目中的所有源代碼文件夾，包含java，jsp等
• 第4行：項目中的所有單元測試文件的文件夾
• 第5～9行：單元測試文件名的正則表達式，這些測試將會在構建結束后運行
• 第11～19行：在創建jar文件時需要拷貝的資源。

Once the build is done, different kinds of reports and documentation can be generated to report the status of the build/release. The target audience of the reports can vary from other developers in the same project to sponsors, stakeholders or users from other projects. For instance, the javadoc and java cross reference (jsr) reports target the programmers, jdepend reports are of interest to the architect. File and developer activity reports might be of interest to the Configuration Manager. The reports are meant to effectively communicate and collaborate with the team and the stakeholders about the project's status. Listing 4 shows the Project Reports Section in the project.xml. Do not worry about the specifics of each of the entries. You can pick them up as you use Maven.

一旦build結束，就會創建各種用于報告build/release狀態的報告和文檔。對報告感興趣的可以是項目中的其他開發者、項目的發起者、項目監理、或者其他項目的人員。例如，程序員關注于javadoc和java cross reference（jsr）報告發送給，系統架構師則更關心jdepend報告，配置管理師則更關心開發者和文件的活動報告。這些報告對項目組內部的溝通和協作以及項目監理對項目狀態的了解都是有意義的。表4對project.xml中的項目報告部分進行了描述。暫且別急于了解其各項的具體內容，在使用Maven的過程中，你會了解它們的。

Listing 4 Project Reports Section in project.xml

<reports>
   <report>maven-changes-pluginreport>
   <report>maven-jdepend-pluginreport>
   <report>maven-checkstyle-pluginreport>
   <report>maven-pmd-pluginreport>
   <report>maven-junit-report-pluginreport>
   <report>maven-clover-pluginreport>
   <report>maven-changelog-pluginreport>
   <report>maven-file-activity-pluginreport>
   <report>maven-developer-activity-pluginreport>
   <report>maven-file-activity-pluginreport>
   <report>maven-license-pluginreport>
   <report>maven-linkcheck-pluginreport>
   <report>maven-jxr-pluginreport>
reports>

The final section covers the Project Dependency and is the key to every project. Consider Listing 5 that shows the dependencies for the Sample Maven Project. The first dependency states that this project depends on a jar file in a folder named BeanUtils. The name of the jar file is commons-beanutils-1.5.jar [according to the id-version.jar convention described earlier]. The folder BeanUtils exists in the .maven/repository folder.

在project.xml中最好一部分是有關項目依賴部分的內容，它正是項目的關鍵部分。在表5中展示了Sample Maven Project的依賴，該項目的第一個依賴是BeanUtils文件夾中一個jar文件，它的名字是commons-beanutils-1.5.jar（根據早些提到的id-version.jar風格）。BeanUtils文件夾位于.maven/repository中。

Listing 5 Project dependency Section in project.xml

表5 project.xml中的項目依賴關系部分

<dependencies>
      <dependency>
        <groupId>BeanUtilsgroupId>
        <artifactId>commons-beanutilsartifactId>
        <version>1.5version>
      dependency>
      <dependency>
        <groupId>commons-logginggroupId>
        <artifactId>commons-loggingartifactId>
        <version>1.0.3version>
      dependency>
      <dependency>
        <groupId>castorgroupId>
        <artifactId>castorartifactId>
        <version>0.9.4.3version>
      dependency>
dependencies>

Maven Hands-On ( Maven動手)

Now that we have sufficient understanding of the project.xml file let us get on try something out. At the time of this writing Maven 1.0 beta 10 - a feature complete version for the 1.0 release is generally available, which we will use in the course of this article. After downloading Maven from maven.apache.org, unzip the archive into your local directory. Set the JAVA_HOME variable to point to the JDK installation and MAVEN_HOME to point to the Maven directory. Also add the MAVEN_HOME/bin to the PATH environment variable. With these settings, you are ready to use Maven.

既然我們對project.xml已經有了一定的了解，那我們就開始動手吧。在寫這篇文章的時候，特性完整的Maven 1.0 release版已經可以下載了，在這篇文章中我們將它進行演示。在從maven.org.maven下載了Maven之后，將它在本機進行解壓縮，設置環境變量JAVA_HOME指向JDK安裝目錄，設置環境變量MAVEN_HOME指向Maven的安裝目錄，將MAVEN_HOME/bin加入到環境變量Path中。當這一切設置好之后，你就可以使用Maven了。

Create a directory structure as shown in Figure 2. Then create a simple MyApp.java class without any dependencies outside JDK libraries. Create a project.xml with the information supplied in Listing 1 through 5. Since your sample project does not depend on external entities, the only exceptions is that you will have an empty dependencies section like this: . Go to the command line and cd to the Sample-Maven-Project directory and type in

C:\Sample-Maven-Project> maven java:compile

You will see that all the java files in src and test directory are compiled. A maven temp directory called target is created directly under C:\Sample-Maven-Project, which contains all the compiled class files. As I have stated earlier Maven's power lies in its plugins. You might not know it, but you have just used one of its plugins. When you typed maven java:compile you signaled Maven to use the "java" plugin and attain the "compile" goal. Maven uses the project.xml and the repository to execute a "goal" on the project. The generic format of the maven command is

maven <plugin name>:<goal name>

按照圖2創建目錄結構，然后新建一個不依賴于JDK庫的MyApp.java文件，創建類如表1到表5構成的project.xml。由于你的Sample project不依賴于任何的外部實體，所以只需將依賴部分設為空即可：。然后轉到命令行方式下，進入Sample-Maven-Project目錄，鍵入下面的命令：

C:\Sample-Maven-Project> maven java:compile

你可以看到src和test目錄下面的所有java文件都已經被編譯了，在C:\Sample-Maven-Project目錄下面，將會創建臨時目錄target，所有的編譯文件都存放于其中。正如我前面所提到的，Maven的威力在于其強大的plug-in。也許你還不知道它，但就在剛才你已經使用了一個plug-in了。當你敲入命令“maven java:compile”的時候，你就是在使用使用“java”plug-in的“compile”goal。Maevn使用project.xml和倉庫對本項目執行“goal”。Maven的統一的命令格式為：

maven <plugin name>:<goal name>

A plugin is a logical collection of goals written using Jelly - an XML based scripting language. The conditional constructs from Jelly control the execution of ready-made ant scripts for the pre defined tasks. Each such task is called a Goal. Although I do not cover Jelly in this article a sample Jelly snippet will make things clear as to how it wraps an Ant script. This snippet is from the Maven java plugin. The plugin internally invokes the to compile the java code.

Plug-in是使用Jelly（基于XML的標記語言）編寫的一系列命令。Jelly中的條件結構（conditional construct,這里指標簽）將會調用Ant中預先定義好任務（task）。每個這樣的任務就被稱為Goal。雖然在這篇文章中，我并不細談Jelly，但我想給出一段Jelly腳本將會有益于讀者理解Jelly是如何封裝Ant的。下面的這段腳本摘于Maven的java plug-in，它將調用對java代碼進行編譯。

<j:when test="${sourcesPresent == 'true'}">
     <ant:javac  destdir="${maven.build.dest}"
                 excludes="**/package.html"
                 debug="${maven.compile.debug}"
                 deprecation="${maven.compile.deprecation}"
                 target="${maven.compile.target}"
                 optimize="${maven.compile.optimize}">
        <ant:src>
          <ant:path refid="maven.compile.src.set"/>
        ant:src>
     j:when>

A plugin may have a default goal. In such a case you just have to type in maven . In this case the compile goal in java plugin has the knowledge to go to the src and test folders specified in the project.xml and recursively compile all the java files. Similarly a jar plugin has a default goal of "jar" - i.e. to jar the class files after compiling. The jar plugin invokes java:compile or something to that effect to compile the java classes first and then creates the jar file from the classes and automatically generates the manifest. A plugin thus captures the common practices into a reusable "library" saving you from reinventing the wheel and cutting and pasting ant scripts. Now let us go ahead and execute the jar:install goal. Type the following on the command linePlug-in可能有默認goal，在這種情況下，你今需要敲入“maven ”即可。在上面的例子中java plugin中的compile可以從project.xml中獲取src和test的設置，然后循環編譯所有的java文件。同樣jar plugin擁有默認goal“jar”－在編譯之后將所有的class文件打包。Jar plugin將會首先調用java:compile或者其他方法編譯java文件，然后將這些class文件打包并自動加入manifest。Plugin正是抓住了實際中這些通用的時間，形成了可復用的“庫”，也就無需再造輪子，到處拷貝粘貼腳本了?，F在我們繼續向前執行jar:install goal，在命令行方式下敲入如下命令：

C:\Sample-Maven-Proejct>maven jar:install

When the jar:install goal is attained, a jar file with name sample-project-1.1.jar is created and is copied into the C:/Documents And Settings//.maven/repository/Sample-Maven-Project/jars folder. This is how you publish artifacts as mentioned earlier in this section and is the basis for continuous integration.

當jar:install執行完畢，將會創建名為sample-project-1.1.jar包并且將它拷貝到目錄C:/Documents And Settings//.maven/repository/ Sample-Maven-Project/jars。這就是本節前面提到的發布制品的方法，它是持續集成的基礎。

You can see all the goals of Maven by typing the command maven -g at the command line. 你可以通過在命令行方式下敲入 maven –g命令查看Maven的所有goal。

C:\Sample-Maven-Proejct>maven jar:install

Written by Srikanth Shenoy November 2003

Translated by jinfeng wang 2005年三月

原文地址：http://www.theserverside.com/articles/article.tss?l=MavenMagic

本文的翻譯已經原作者同意，轉載請保持原文。如有問題和意見可以和原作者或我聯系。
Part 2 :http://www.tkk7.com/jinfeng_wang/archive/2005/03/14/2074.html
Part 3 :http://www.tkk7.com/jinfeng_wang/archive/2005/03/15/2089.html