Maven是Apache组织下的一个跨平台的项目管理工具

1、Maven是Apache组织下的一个跨平台的项目管理工具，它主要用来帮助实现项目的构建、测试、打包和部署。Maven提供了标准的软件生命周期模型和构建模型，通过配置就能对项目进行全面的管理。它的跨平台性保证了在不同的操作系统上可以使用相同的命令来完成相应的任务。Maven将构建的过程抽象成一个个的生命周期过程，在不同的阶段使用不同的已实现插件来完成相应的实际工作，这种设计方法极大的避免了设计和脚本编码的重复，极大的实现了复用。索引预览：1. maven基础2. 插件和仓库，设置代理3. 依赖，聚合，继承4. maven属性，5. maven生命周期，phases阶段，goal目标。6. mav

2、en仓库7. 补充内容：生成可执行jar依赖树配置文件profilemavengoal目标src/main/javasrc/main/resourcessrc/main/filterssrc/main/assembly src/main/config src/main/scripts src/main/webapp src/test/java src/test/resources src/test/filters src/site LICENSE.txt README.txt表1.Maven目录结构Application/LibrarysourcesApplication/Libraryres

3、ourcesResourcefilterfilesAssemblydescriptorsConfigurationfilesApplication/LibraryscriptsWebapplicationsourcesTestsourcesTestresourcesTestresourcefilterfilesSiteProject'slicenseProject'sreadme项目对象模型POM-Maven的灵魂POM即ProjectObjectModule,项目对象模型，在pom.xml文件中定义了项目的基本信息、源代码、配置文件、开发者的信息和角色、问题追踪系统、组织信息

4、、项目授权、项目的url、以及构建项目所用的插件，依赖继承关系。开发人员需按照maven定义的规则进行POM文件的编写，清单1为一个POM文件示例。清单1.POM文件示例<projectxmlns="/POM/4.0.0"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/POM/4.0.0/maven-v4_0_0

5、.xsd"><modelVersion>4.0.0</modelVersion>< !-TheBasics-><groupId></groupId><artifactId></artifactId><version></version><packaging></packaging><dependencies></dependencies><parent></parent><dependencyM

6、anagement></dependencyManagement><modules></modules><properties></properties>< !-BuildSettings-><build></build>reporting/reporting< !-MoreProjectInformation-><name></name><description></descdp><url></url><

7、;inceptionYear></inceptionYear><licenses></licenses><organization></organization><developers></developers><contributors></contributors>< !-EnvironmentSettings-><issueManagement></issueManagement><ciManagement></ciMan

8、agement><mailingLists></mailingLists><scm></scm><prerequisites></prerequisites><repositories></repositories><pluginRepositories></pluginRepositories><distributionManagement></distributionManagement><profiles></profil

9、es></project>Maven插件和仓库Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，仅仅定义了抽象的生命周期，所有这些任务都交给插件来完成的。每个插件都能完成至少一个任务，每个任务即是一个功能，将这些功能应用在构建过程的不同生命周期中。这样既能保证拿来即用，又能保证maven本身的繁杂和冗余。例如清单2中的代码就是要在validate这个阶段执行maven-antrun-plugin的run目标，具体的任务在<target></target>元素中定义。清单2.插件<plugins><plugin>

10、<groupId>org.apache.maven.plugins</groupId><artifactId>maven-antrun-plugin</artifactId><version>1.6</version><executions><execution><id>version</id><phase>validate</phase><configuration><target>具体任务</target><

11、;/configuration><goals><goal>run</goal></goals></execution></executions></plugin></plugins>设置代理：当个人所在的网络无法访问公共的Maven仓库时，可以在settings.xml中设置代理服务器。打开.m2settings.xml,如果没有则复制$Maven_HOME/conf/settings.xml到此路径下，加入清单3中的代码：清单3.代理<proxies><proxy>&

12、lt;active>true</active><protocol>http</protocol><host>代理地址</host><port>8080</port><username>用户名</username><password>密码</password></proxy></proxies>依赖、聚合和继承依赖我们项目中依赖的Jar包可以通过依赖的方式引入，通过在dependencies元素下添加dependency子元素，可以声明

13、一个或多个依赖。通过控制依赖的范围，可以指定该依赖在什么阶段有效。Maven的几种依赖范围：表2.依赖范围名称有效范围compile编译，测试，运行。默认的依赖范围。test测试，如Junitoruntime运行，如JDBC。provided编译，测试，如ServletAPI。system编译，测试，依赖于系统变量。清单4中表示引入对Junit的依赖，这个依赖关系产生作用的阶段是<scope>test</scope>清单4.依赖<dependency><groupId></groupId><artifactId></

14、artifactId><version></version><optional>true<optional></dependency>依赖是具有传递性的，例如ProjectA依赖于ProjectB,B依赖于C,那么B对C的依赖关系也会传递给A,如果我们不需要这种传递性依赖，也可以用<optional>去除这种依赖的传递，如清单5。清单5.选择性依赖<dependency><groupId>commons-logging</groupId><artifactId>comm

15、ons-logging</artifactId><version>1.1.1</version><optional>true<optional></dependency>假设第三方的jar包中没有使用<optional>来去除某些依赖的传递性，那么可以在当前的POM文件中使用<exclusions>元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。如清单6。清单6.排除依赖<dependency><groupId

16、>org.springframework</groupId><artifactId>spring-core</artifactId><exclusions><exclusion><groupId>commons-logging</groupId><artifactId>commons-logging</artifactId></exclusion></exclusions></dependency>聚合现实中一个项目往往是由多个project构成

17、的，在进行构建时，我们当然不想针对多个project分别执行多次构建命令，这样极容易产生遗漏也会大大降低效率。Maven的聚合功能可以通过一个父模块将所有的要构建模块整合起来，将父模块的打包类型声明为POM,通过<modules>将各模块集中到父POM中如清单7,其中<module></module>中间的内容为子模块工程名的相对路径。清单7.聚合<modules><module>./ject1</module><module>./ject2</mo

18、dule></modules>父类型的模块，不需要有源代码和资源文件，也就是说，没有src/main/java和src/test/java目录。Maven会首先解析聚合模块的POM文件，分析要构建的模块，并通过各模块的依赖关系计算出模块的执行顺序，根据这个潜在的关系依次构建模块。将各子模块聚合到父模块中后，我们就可以对父模块进行一次构建命令来完成全部模块的构建。继承在面向对象的编程中我们学会了继承的概念，继承是可重用行即消除重复编码的行为。Maven中继承的用意和面向对象编程中是一致的。与聚合的实现类似，我们通过构建父模块将子模块共用的依赖，插件等进行统一声明，在聚合和继承同

19、时使用时，我们可以用同一个父模块来完成这两个功能。例如将com.dugeng.parent这个模块声明为projectl和project2的父模块，那么我们在projectl和2中用如下代码声明父子关系，如清单8:清单8.继承<parent><groupId>com.dugeng.mavenproject</groupId><artifactId>com.dugeng.parent</artifactId><version>0.0.1-SNAPSHOT</version><relativePath>

20、./com.dugeng.parent/pom.xml</relativePath></parent>由于父模块只是用来声明一些可共用的配置和插件信息，所以它也像聚合模块一样只需要包括一个POM文件，其它的项目文件如src/main/java是不需要的。聚合和继承存在一些共性和潜在的联系，在实际的应用中，经常将聚合模块的父模块和继承的父模块定义为同一个。并不是所有的POM元素都可以被继承Maven属性在POM文件中常常需要引用已定义的属性以降低代码的冗余，提高代码的可重用性，这样不仅能降低代码升级的工作量也能提高代码的正确率。有些属性是用户自定义的，有些属性是可以直接引

21、用的已定义变量。Maven的可用属性类型可分为5种，它们分别是：内置属性。这种属性跟MavenProject自身有关，比如要引入当前Project的版本信息，那么只需要在使用的位置引用$version就行了。Setting属性。上文中已经提到Maven自身有一个settings.xml配置文件，它里面含有包括仓库，代理服务器等一些配置信息，利用$settings.somename就可以得到文件里相应元素的值。POM属性。这种属性对应POM文件中对应元素的值，例如$project.groupId对应了<groupId></groupId>中的值，$project.arti

22、factId对应了<artifactId></artifactId>中的值。系统环境变量。可以使用env.$name来获得相应name对应的环境变量的值，例如$env.JAVA_HOME得到的就是JAVA_HOME的环境变量值。用户自定义变量。这种类型的变量是使用最频繁和广泛的变量，完全由用户自己定义。在POM文件中加入<properties>元素并将自定义属性作为其子元素。格式如清单9。清单9.自定义属性<properties><path>././sourcecode</path></properties>在

23、上一篇文章中，我们用的第二个命令是：mvnpackage这里的package是一个maven的生命周期阶段(lifecyclephase)。生命周期指项目的构建过程，它包含了一系列的有序的阶段(phase)而一个阶段就是构建过程中的一个步骤。那么生命周期阶段和上面说的插件目标之间是什么关系呢？插件目标可以绑定到生命周期阶段上。一个生命周期阶段可以绑定多个插件目标。当maven在构建过程中逐步的通过每个阶段时，会执行该阶段所有的插件目标。maven能支持不同的生命周期，但是最常用的是默认的Maven生命周期(defaultMavenlifecycle)。如果你没有对它进行任何的插件配置或者定制的

24、话，那么上面的命令mvnpackage会依次执行默认生命周期中直到包括package阶段前的所有阶段的插件目标：Maven生命周期phases阶段validate:validatetheprojectiscorrectandallnecessaryinformationisavailablecompile:compilethesourcecodeoftheprojecttest:testthecompiledsourcecodeusingasuitableunittestingframework.Thesetestsshouldnotrequirethecodebepackagedordepl

25、oyedpackage:takethecompiledcodeandpackageitinitsdistributableformat,suchasaJAR.integration-test:processanddeploythepackageifnecessaryintoanenvironmentwhereintegrationtestscanberunverify:runanycheckstoverifythepackageisvalidandmeetsqualitycriteriainstall:installthepackageintothelocalrepository,foruse

26、asadependencyinotherprojectslocallydeploy:doneinanintegrationorreleaseenvironment,copiesthefinalpackagetotheremoterepositoryforsharingwithotherdevelopersandprojects.TherearetwootherMavenlifecyclesofnotebeyondthedefaultlistabove.Theyareclean:cleansupartifactscreatedbypriorbuildssite:generatessitedocu

27、mentationforthisprojectgoal,phases,lifeclyc阍区别:maven对构建(build)的过程进行了抽象和定义，这个过程被称为构建的生命周期(lifecycle)。生命周期(lifecycle)由多个阶段(phase)ffl成，每个阶段(phase会挂接一到多个goalgoal是maven里定义任务的最小单元，相当于ant里的target。因此，goal其实是由存在于Maven的repository中的plugin提供的一个个小的功能程序它是Maven的lifecycle以及phase的基本组成元素。同时，我们也可以通过将各种各样的goal加入到Maven的

28、phase中，从而根据自己的实际需求，灵活实现各种定制功能。构建：以phase为目标构建以phase为目标进行构建是最常见的，如我们平时经常执行的mvncompile,mvntest,mvnpackage.等,compile,test,package者B是maven生命周期(lifecycle)里的phase通过mvn命令，你可以指定一次构建执行到那一个阶段，在执行过程中，所有经历的执行阶段(phase)k绑定的goal都将得到执行。例如，对于一个jar包应用，当执行mvnpackage命令时，maven从validate阶段一个阶段一个阶段的执行，在执行到compile阶段时，compile

29、r插件的compilegoal会被执行，因为这个goal是绑定在compile阶段(phase)k的。以goal为目标构建虽然以phase为目标的构建最常见，但是有时候我们会发现，一些插件的goal并不适合绑定到任何阶段(phase)k,或者是，这些goal往往是单独执行，不需要同某个阶段(phase绑定在一起，比如hibernate插件的导入导出goal多数情况下是根据需要要手动执行的(当然，也可以绑定到某个阶段上，比如进行单元测试时，可考虑将其绑定到test阶段上)。每个阶段对应的内置插件目标goalCleanLifecycleBindingscleanclean:cleanDefault

30、LifecycleBindings-Packagingejb/ejb3/jar/par/rar/warprocess-resourcesresources:resourcescompilecompiler:compileprocess-test-resourcesresources:testResourcestest-compilecompiler:testCompiletestsurefire:testpackageejb:ejborejb3:ejb3orjar:jarorpar:parorrar:rarorwar:warinstallinstall:installdeploydeploy:

31、deployDefaultLifecycleBindings-Packagingeargenerate-resourcesear:generate-application-xmlprocess-resourcesresources:resourcespackageear:earinstallinstall:installdeploydeploy:deployDefaultLifecycleBindings-Packagingmaven-plugingenerate-resourcesplugin:descriptorprocess-resourcesresources:resourcescom

32、pilecompiler:compileprocess-test-resourcesresources:testResourcestest-compilecompiler:testCompiletestsurefire:testpackagejar:jarandplugin:addPluginArtifactMetadatainstallinstall:installdeploydeploy:deployDefaultLifecycleBindings-Packagingpompackagesite:attach-descriptorinstallinstall:installdeployde

33、ploy:deploySiteLifecycleBindingssitesite:sitesite-deploysite:deployMaven库当第一次运行maven命令的时候，你需要Internet连接，因为它要从网上下载一些文件。那么它从哪里下载呢？它是从maven默认的远程库(/maven2)下载的。这个远程库有maven的核心插件和可供下载的jar文件。但是不是所有的jar文件都是可以从默认的远程库下载的，比如说我们自己开发的项目。这个时候，有两个选择：要么在公司内部设置定制库，要么手动下载和安装所需的jar文件到本地库。本地库是指maven

34、下载了插件或者jar文件后存放在本地机器上的拷贝。在Linux上，它的位置在/.m2/repository,在WindowsXP上，在C:DocumentsandSettingsusername.m2repository,在Windows7上，在C:Usersusername.m2repository当maven查找需要的jar文件时，它会先在本地库中寻找，只有在找不到的情况下，才会去远程库中找。运行下面的命令能把我们的helloworld项目安装到本地库:$mvninstall一旦一个项目被安装到了本地库后，你别的项目就可以通过maven坐标和这个项目建立依赖关系补充说明几点技巧：1 .可执

35、行的JAR文件使用Maven构建一个JAR文件比较容易：只要定义项目包装为“jar,”然后执行包装生命周期阶段即可。但是定义一个可执行JAR文件却比较麻烦。采取以下步骤可以更高效：在您定义可执行类的JAR的MANIFEST.MF文件中定义一个main类。（MANIFEST.MF是包装您的应用程序时Maven生成的。）找到您项目依赖的所有库。在您的MANIFEST.MF文件中包含那些库，便于您的应用程序找到它们。您可以手工进行这些操作，或者要想更高效，您可以使用两个Maven插件帮助您完成：maven-jar-plugin和maven-dependency-pluginmaven-jar-plu

36、ginmaven-jar-plugin可以做很多事情，但在这里，我们只对使用它来修改默认MANIFEST.MF文件的内容感兴趣。在您的POM文件的插件部分添加清单1所示代码：清单1.使用maven-jar-plugin修改MANIFEST.MF<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-jar-plugin</artifactId><configuration><archive><manifest><

37、addClasspath>true</addClasspath><classpathPre巾x>lib/</classpathPre巾x><mainClass>com.mypackage.MyClass</mainClass></manifest></archive></configuration></plugin>所有Maven插件通过一个configuration元素公布了其配置，在本例中，maven-jar-plugin修改它的archive属性，特别是存档文件的manife

38、st属性，它控制MANIFEST.MF文件的内容。包括3个元素：addClassPath将该元素设置为true告知maven-jar-plugin添加一个Class-Path元素到MANIFEST.MF文件，以及在Class-Path元素中包括所有依赖项。classpathPrefix：如果您计划在同一目录下包含有您的所有依赖项，作为您将构建的JAR,那么您可以忽略它；否则使用classpathPrefix来指定所有依赖JAR文件的前缀。在清单1中，classpathPrefix指出，相对存档文件，所有的依赖项应该位于“lib文件夹。mainClass：当用户使用lib命令执行JAR文件时，使

39、用该元素定义将要执行的类名。maven-dependency-plugin当您使用这3个元素配置好了MANIFEST.MF文件之后，下一步是将所有的依赖项复制到lib文件夹。为此，使用maven-dependency-plugin，如清单2所清单2.使用maven-dependency-plugin将依赖项复制到库<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-dependency-plugin</artifactId><execution

40、s><execution><id>copy</id><phase>install</phase><goals><goal>copy-dependencies</goal></goals><configuration><outputDirectory>$project.build.directory/lib</outputDirectory>maven-dependency-plugin有个copy-dependencies目标是将您的依赖项复制到

41、您所选择的目录。本例中，我将依赖项复制到build目录下的lib目录(project-home/target/lib)。将您的依赖项和修改的MANIFEST.MF放在适当的位置后，您就可以用一个简单的命令启动应用程序：java-jarjarfilename.jar2 .依赖项树Maven一个最有用的功能是它支持依赖项管理：您只需要定义您应用程序依赖的库，Maven找到它们、下载它们、然后使用它们编译您的代码。必要时，您需要知道具体依赖项的来源一这样您就可以找到同一个JAR文件的不同版本的区别和矛盾。这种情况下，您将需要防止将一个版本的JAR文件包含在您的构建中，但是首先您需要定位保存JAR的依

42、赖项。一旦您知道下列命令，那么定位依赖项往往是相当容易的:mvndependency:treedependency:tree参数显示您的所有直接依赖项，然后显示所有子依赖项（以及它们的子依赖项，等等）。例如，清单5节选自我的一个依赖项所需要的客户端库：清单5.Maven依赖项树INFOINFOBuildingClientlibraryforcommunicatingwiththeLDEINFOtask-segment:dependency:treeINFOINFOdependency:treeexecution:default-cliINFOcom.lmt.pos:sis-client:jar

43、:2.1.14INFO+-org.codehaus.woodstox:woodstox-core-lgpl:jar:4.0.7:compileINFO|-org.codehaus.woodstox:stax2-api:jar:3.0.1:compileINFO+-org.easymock:easymockclassextension:jar:2.5.2:testINFO|+-cglib:cglib-nodep:jar:2.2:testINFO|-org.objenesis:objenesis:jar:1.2:test在清单5中您可以看到sis-client项目需要woodstox-core-l

44、gpl和easymockclassextension库。easymockclassextension库反过来需要cglib-nodep库和objenesis库。如果我的objenesis出了问题，比如出现两个版本，1.2和1.3,那么这个依赖项树可能会向我显示，1.2工件是直接由easymockclassextension库导入的。dependency:tree参数为我节省了很多调试时间，我希望对您也同样有帮助。3 .使用配置文件多数重大项目至少有一个核心环境，由开发相关的任务、质量保证（QA）、集成和生产组成。管理所有这些环境的挑战是配置您的构建，这必须连接到正确的数据库中，执行正确的脚本集

45、、并为每个环境部署正确的工件。使用Maven配置文件让您完成这些任务，而无需为每个环境分别建立明确指令。关键在于环境配置文件和面向任务的配置文件的合并。每个环境配置文件定义其特定的位置、脚本和服务器。因此，在我的pox.xml文件中，我将定义面向任务的配置文件“deploywar,”如清单6所示：清单6.部署配置文件<profiles><profile><id>deploywar</id><build><plugins><plugin><groupId>net.fpic</groupId>

46、;<artifactId>tomcat-deployer-plugin</artifactId><version>1.0-SNAPSHOT</version><executions><execution><id>pos</id><phase>install</phase><goals><goal>deploy</goal></goals><configuration><host>$deploymentMa

47、nagerRestHost</host><port>$deploymentManagerRestPort</port><username>$deploymentManagerRestUsername</username><password>$deploymentManagerRestPassword</password><artifactSource>address/target/addressservice.war</artifactSource>这个配置文件（通过ID“deployw

48、ar区别）执行tomcat-deployer-plugin,被配置来连接一个特定主机和端口，以及指定用户名和密码证书。所有这些信息使用变量来定义，比如$deploymentmanagerRestHost。这些变量在我的profiles.xml文件中定义，如清单7所示：清单7.profiles.xml<!-Definesthedevelopmentdeploymentinformation-><profile><id>dev</id><activation><property><name>env</name><value>dev</value></property></activation><properties><deploymentManagerRestHost>2</deploymentMana