Maven中pom.xml详解

文章目录[隐藏]

基础配置
构建配置
分发配置
仓库配置
profile 配置
报表配置
环境配置
项目信息配置

setting.xml 主要用于配置 maven 的运行环境等一系列通用的属性，是全局级别的配置文件；而 pom.xml 主要描述了项目的 maven 坐标，依赖关系，开发者需要遵循的规则，缺陷管理系统，组织和 licenses，以及其他所有的项目相关因素，是项目级别的配置文件。

基础配置

一个典型的 pom.xml 文件配置如下：

<project xmlns=“http://maven.apache.org/POM/4.0.0” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd”>
<!– 模型版本。maven2.0 必须是这样写，现在是 maven2 唯一支持的版本 –>
<modelVersion>4.0.0</modelVersion>
<!– 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成，如 com.winner.trade，maven 会将该项目打成的 jar 包放本地路径：/com/winner/trade –>
<groupId>com.winner.trade</groupId>
<!– 本项目的唯一 ID，一个 groupId 下面可能多个项目，就是靠 artifactId 来区分的 –>
<artifactId>trade-core</artifactId>
<!– 本项目目前所处的版本号 –>
<version>1.0.0-SNAPSHOT</version>
<!– 打包的机制，如 pom,jar, maven-plugin, ejb, war, ear, rar, par，默认为 jar –>
<packaging>jar</packaging>
<!– 帮助定义构件输出的一些附属构件,附属构件与主构件对应，有时候需要加上 classifier 才能唯一的确定该构件不能直接定义项目的 classifer,因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成的 –>
<classifier>…</classifier>
<!– 定义本项目的依赖关系 –>
<dependencies>
<!– 每个 dependency 都对应这一个 jar 包 –>
<dependency>
<!–一般情况下，maven 是通过 groupId、artifactId、version 这三个元素值（俗称坐标）来检索该构件，然后引入你的工程。如果别人想引用你现在开发的这个项目（前提是已开发完毕并发布到了远程仓库），–>
<!–就需要在他的 pom 文件中新建一个 dependency 节点，将本项目的 groupId、artifactId、version 写入， maven 就会把你上传的 jar 包下载到他的本地 –>
<groupId>com.winner.trade</groupId>
<artifactId>trade-test</artifactId>
<version>1.0.0-SNAPSHOT</version>
<!– maven 认为，程序对外部的依赖会随着程序的所处阶段和应用场景而变化，所以 maven 中的依赖关系有作用域(scope)的限制。 –>
<!–scope 包含如下的取值：compile（编译范围）、provided（已提供范围）、runtime（运行时范围）、test（测试范围）、system（系统范围） –>
<scope>test</scope>
<!– 设置指依赖是否可选，默认为 false,即子项目默认都继承:为 true,则子项目必需显示的引入，与 dependencyManagement 里定义的依赖类似 –>
<optional>false</optional>
<!– 屏蔽依赖关系。比如项目中使用的 libA 依赖某个库的 1.0 版，libB 依赖某个库的 2.0 版，现在想统一使用 2.0 版，就应该屏蔽掉对 1.0 版的依赖 –>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<!– 为 pom 定义一些常量，在 pom 中的其它地方可以直接引用使用方式如下：${file.encoding} –>
<properties>
<file.encoding>UTF-8</file.encoding>
<java.source.version>1.5</java.source.version>
<java.target.version>1.5</java.target.version>
</properties>
…
</project>

一般来说，上面的几个配置项对任何项目都是必不可少的，定义了项目的基本属性。

这里有必要对一个不太常用的属性classifier做一下解释，因为有时候引用某个 jar 包，classifier 不写的话会报错。

classifier 元素用来帮助定义构件输出的一些附属构件。附属构件与主构件对应，比如主构件是 kimi-app-2.0.0.jar，该项目可能还会通过使用一些插件生成如 kimi-app-2.0.0-javadoc.jar （Java文档）、 kimi-app-2.0.0-sources.jar（Java源代码）这样两个附属构件。这时候，javadoc、sources 就是这两个附属构件的 classifier，这样附属构件也就拥有了自己唯一的坐标。

classifier 的用途在于:

1. maven download javadoc / sources jar 包的时候，需要借助 classifier 指明要下载那个附属构件

2. 引入依赖的时候，有时候仅凭 groupId、artifactId、version 无法唯一的确定某个构件，需要借助 classifier 来进一步明确目标。比如 JSON-lib，有时候会同一个版本会提供多个 jar 包，在 JDK1.5 环境下是一套，在 JDK1.3 环境下是一套：

引用它的时候就要注明 JDK 版本，否则 maven 不知道你到底需要哪一套 jar 包：

<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>

构建配置

<build>
<!– 产生的构件的文件名，默认值是${artifactId}-${version}。 –>
<finalName>myPorjectName</finalName>
<!– 构建产生的所有文件存放的目录,默认为${basedir}/target，即项目根目录下的 target –>
<directory>${basedir}/target</directory>
<!–当项目没有规定目标（Maven2 叫做阶段（phase））时的默认值， –>
<!–必须跟命令行上的参数相同例如 jar:jar，或者与某个阶段（phase）相同例如 install、compile 等 –>
<defaultGoal>install</defaultGoal>
<!–当 filtering 开关打开时，使用到的过滤器属性文件列表。 –>
<!–项目配置信息中诸如${spring.version}之类的占位符会被属性文件中的实际值替换掉 –>
<filters>
<filter>../filter.properties</filter>
</filters>
<!–项目相关的所有资源路径列表，例如和项目相关的配置文件、属性文件，这些资源被包含在最终的打包文件里。 –>
<resources>
<resource>
<!–描述了资源的目标路径。该路径相对 target/classes 目录（例如${project.build.outputDirectory}）。 –>
<!–举个例子，如果你想资源在特定的包里(org.apache.maven.messages)，你就必须该元素设置为 org/apache/maven/messages。 –>
<!–然而，如果你只是想把资源放到源码目录结构里，就不需要该配置。 –>
<targetPath>resources</targetPath>
<!–是否使用参数值代替参数名。参数值取自 properties 元素或者文件里配置的属性，文件在 filters 元素里列出。 –>
<filtering>true</filtering>
<!–描述存放资源的目录，该路径相对 POM 路径 –>
<directory>src/main/resources</directory>
<!–包含的模式列表 –>
<includes>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
<!–排除的模式列表如果<include>与<exclude>划定的范围存在冲突，以<exclude>为准 –>
<excludes>
<exclude>jdbc.properties</exclude>
</excludes>
</resource>
</resources>
<!–单元测试相关的所有资源路径，配制方法与 resources 类似 –>
<testResources>
<testResource>
<targetPath />
<filtering />
<directory />
<includes />
<excludes />
</testResource>
</testResources>
<!–项目源码目录，当构建项目的时候，构建系统会编译目录里的源码。该路径是相对于 pom.xml 的相对路径。 –>
<sourceDirectory>${basedir}\src\main\java</sourceDirectory>
<!–项目脚本源码目录，该目录和源码目录不同， <!– 绝大多数情况下，该目录下的内容会被拷贝到输出目录(因为脚本是被解释的，而不是被编译的)。 –>
<scriptSourceDirectory>${basedir}\src\main\scripts
</scriptSourceDirectory>
<!–项目单元测试使用的源码目录，当测试项目的时候，构建系统会编译目录里的源码。该路径是相对于 pom.xml 的相对路径。 –>
<testSourceDirectory>${basedir}\src\test\java</testSourceDirectory>
<!–被编译过的应用程序 class 文件存放的目录。 –>
<outputDirectory>${basedir}\target\classes</outputDirectory>
<!–被编译过的测试 class 文件存放的目录。 –>
<testOutputDirectory>${basedir}\target\test-classes
</testOutputDirectory>
<!–项目的一系列构建扩展,它们是一系列 build 过程中要使用的产品，会包含在 running bulid‘s classpath 里面。 –>
<!–他们可以开启 extensions，也可以通过提供条件来激活 plugins。 –>
<!–简单来讲，extensions 是在 build 过程被激活的产品 –>
<extensions>
<!–例如，通常情况下，程序开发完成后部署到线上 Linux 服务器，可能需要经历打包、 –>
<!–将包文件传到服务器、SSH 连上服务器、敲命令启动程序等一系列繁琐的步骤。 –>
<!–实际上这些步骤都可以通过Maven的一个插件 wagon-maven-plugin 来自动完成 –>
<!–下面的扩展插件 wagon-ssh 用于通过 SSH 的方式连接远程服务器， –>
<!–类似的还有支持 ftp 方式的 wagon-ftp 插件 –>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>2.8</version>
</extension>
</extensions>
<!–使用的插件列表。 –>
<plugins>
<plugin>
<groupId></groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.5</version>
<!–在构建生命周期中执行一组目标的配置。每个目标可能有不同的配置。 –>
<executions>
<execution>
<!–执行目标的标识符，用于标识构建过程中的目标，或者匹配继承过程中需要合并的执行目标 –>
<id>assembly</id>
<!–绑定了目标的构建生命周期阶段，如果省略，目标会被绑定到源数据里配置的默认阶段 –>
<phase>package</phase>
<!–配置的执行目标 –>
<goals>
<goal>single</goal>
</goals>
<!–配置是否被传播到子 POM –>
<inherited>false</inherited>
</execution>
</executions>
<!–作为 DOM 对象的配置,配置项因插件而异 –>
<configuration>
<finalName>${finalName}</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptor>assembly.xml</descriptor>
</configuration>
<!–是否从该插件下载Maven扩展（例如打包和类型处理器）， –>
<!–由于性能原因，只有在真需要下载时，该元素才被设置成 true。 –>
<extensions>false</extensions>
<!–项目引入插件所需要的额外依赖 –>
<dependencies>
<dependency>…</dependency>
</dependencies>
<!–任何配置是否被传播到子项目 –>
<inherited>true</inherited>
</plugin>
</plugins>
<!–主要定义插件的共同元素、扩展元素集合，类似于 dependencyManagement， –>
<!–所有继承于此项目的子项目都能使用。该插件配置项直到被引用时才会被解析或绑定到生命周期。 –>
<!–给定插件的任何本地配置都会覆盖这里的配置 –>
<pluginManagement>
<plugins>…</plugins>
</pluginManagement>
</build>

pom 里面的仓库与 setting.xml 里的仓库功能是一样的。主要的区别在于，pom 里的仓库是个性化的。比如一家大公司里的 setting 文件是公用的，所有项目都用一个 setting 文件，但各个子项目却会引用不同的第三方库，所以就需要在 pom 里设置自己需要的仓库地址。

分发配置

<!–项目分发信息，在执行 mvn deploy 后表示要发布的位置。 –>
<!–有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库。 –>
<distributionManagement>
<!–部署项目产生的构件到远程仓库需要的信息 –>
<repository>
<!–是分配给快照一个唯一的版本号（由时间戳和构建流水号），还是每次都使用相同的版本号 –>
<!–参见 repositories/repository 元素 –>
<uniqueVersion>true</uniqueVersion>
<id> repo-id </id>
<name> repo-name</name>
<url>file://${basedir}/target/deploy </url>
<layout />
</repository>
<!–构件的快照部署到哪里,如果没有配置该元素，默认部署到 repository 元素配置的仓库 –>
<snapshotRepository>
<uniqueVersion />
<id />
<name />
<url />
<layout />
</snapshotRepository>
<!–部署项目的网站需要的信息 –>
<site>
<!–部署位置的唯一标识符，用来匹配站点和 settings.xml 文件里的配置 –>
<id> site-id </id>
<!–部署位置的名称 –>
<name> site-name</name>
<!–部署位置的 URL，按 protocol://hostname/path 形式 –>
<url>scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web </url>
</site>
<!–项目下载页面的 URL。如果没有该元素，用户应该参考主页。 –>
<!–使用该元素的原因是：帮助定位那些不在仓库里的构件（由于 license 限制）。 –>
<downloadUrl />
<!–如果构件有了新的 groupID 和 artifact ID（构件移到了新的位置），这里列出构件的重定位信息。 –>
<relocation>
<!–构件新的 group ID –>
<groupId />
<!–构件新的 artifact ID –>
<artifactId />
<!–构件新的版本号 –>
<version />
<!–显示给用户的，关于移动的额外信息，例如原因。 –>
<message />
</relocation>
<!–给出该构件在远程仓库的状态。不得在本地项目中设置该元素，因为这是工具自动更新的。 –>
<!–有效的值有：none（默认），converted（仓库管理员从Maven 1 POM 转换过来）， –>
<!–partner（直接从伙伴Maven 2 仓库同步过来），deployed（从Maven 2 实例部署），verified（被核实时正确的和最终的）。 –>
<status />
</distributionManagement>

仓库配置

<!–发现依赖和扩展的远程仓库列表。 –>
<repositories>
<!–包含需要连接到远程仓库的信息 –>
<repository>
<!–如何处理远程仓库里发布版本的下载 –>
<releases>
<!–true 或者 false 表示该仓库是否为下载某种类型构件（发布版，快照版）开启。 –>
<enabled />
<!–该元素指定更新发生的频率。Maven会比较本地 POM 和远程 POM 的时间戳。 –>
<!–这里的选项是：always（一直），daily（默认，每日）， –>
<!–interval：X（这里 X 是以分钟为单位的时间间隔），或者 never（从不）。 –>
<updatePolicy />
<!–当Maven验证构件校验文件失败时该怎么做： –>
<!–ignore（忽略），fail（失败），或者 warn（警告）。 –>
<checksumPolicy />
</releases>
<!–如何处理远程仓库里快照版本的下载。有了 releases 和 snapshots 这两组配置， –>
<!–POM 就可以在每个单独的仓库中，为每种类型的构件采取不同的策略。 –>
<!–例如，可能有人会决定只为开发目的开启对快照版本下载的支持 –>
<snapshots>
<enabled />
<updatePolicy />
<checksumPolicy />
</snapshots>
<!–远程仓库唯一标识符。可以用来匹配在 settings.xml 文件里配置的远程仓库 –>
<id> repo-id </id>
<!–远程仓库名称 –>
<name> repo-name</name>
<!–远程仓库 URL，按 protocol://hostname/path 形式 –>
<url>http://192.168.1.169:9999/repository/ </url>
<!–用于定位和排序构件的仓库布局类型-可以是 default（默认）或者 legacy（遗留）。 –>
<!–Maven 2 为其仓库提供了一个默认的布局； –>
<!–然而，Maven1.x 有一种不同的布局。 –>
<!–我们可以使用该元素指定布局是 default（默认）还是 legacy（遗留）。 –>
<layout> default</layout>
</repository>
</repositories>
<!–发现插件的远程仓库列表，这些插件用于构建和报表 –>
<pluginRepositories>
<!–包含需要连接到远程插件仓库的信息.参见 repositories/repository 元素 –>
<pluginRepository />
</pluginRepositories>

profile 配置

<!–在列的项目构建 profile，如果被激活，会修改构建处理 –>
<profiles>
<!–根据环境参数或命令行参数激活某个构建处理 –>
<profile>
<!–自动触发 profile 的条件逻辑。Activation 是 profile 的开启钥匙。 –>
<activation>
<!–profile 默认是否激活的标识 –>
<activeByDefault>false</activeByDefault>
<!–activation 有一个内建的 java 版本检测，如果检测到 jdk 版本与期待的一样，profile 被激活。 –>
<jdk>1.7</jdk>
<!–当匹配的操作系统属性被检测到，profile 被激活。os 元素可以定义一些操作系统相关的属性。 –>
<os>
<!–激活 profile 的操作系统的名字 –>
<name>Windows XP</name>
<!–激活 profile 的操作系统所属家族(如 ‘windows’) –>
<family>Windows</family>
<!–激活 profile 的操作系统体系结构 –>
<arch>x86</arch>
<!–激活 profile 的操作系统版本 –>
<version>5.1.2600</version>
</os>
<!–如果Maven检测到某一个属性（其值可以在 POM 中通过${名称}引用），其拥有对应的名称和值，Profile 就会被激活。 –>
<!– 如果值字段是空的，那么存在属性名称字段就会激活 profile，否则按区分大小写方式匹配属性值字段 –>
<property>
<!–激活 profile 的属性的名称 –>
<name>mavenVersion</name>
<!–激活 profile 的属性的值 –>
<value>2.0.3</value>
</property>
<!–提供一个文件名，通过检测该文件的存在或不存在来激活 profile。missing 检查文件是否存在，如果不存在则激活 profile。 –>
<!–另一方面，exists 则会检查文件是否存在，如果存在则激活 profile。 –>
<file>
<!–如果指定的文件存在，则激活 profile。 –>
<exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</exists>
<!–如果指定的文件不存在，则激活 profile。 –>
<missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</missing>
</file>
</activation>
<id />
<build />
<modules />
<repositories />
<pluginRepositories />
<dependencies />
<reporting />
<dependencyManagement />
<distributionManagement />
<properties />
</profile>

profile 配置项在 setting.xml 中也有，是 pom.xml 中 profile 元素的裁剪版本，包含了 id，activation, repositories, pluginRepositories 和 properties 元素。这里的 profile 元素只包含这五个子元素是因为 setting.xml 只关心构建系统这个整体（这正是 settings.xml 文件的角色定位），而非单独的项目对象模型设置。如果一个 settings 中的 profile 被激活，它的值会覆盖任何其它定义在 POM 中或者 profile.xml 中的带有相同 id 的 profile。

pom.xml 中的 profile 可以看做 pom.xml 的副本，拥有与 pom.xml 相同的子元素与配置方法。它包含可选的 activation（profile 的触发器）和一系列的 changes。例如 test 过程可能会指向不同的数据库（相对最终的 deployment）或者不同的 dependencies 或者不同的 repositories，并且是根据不同的 JDK 来改变的。只需要其中一个成立就可以激活 profile，如果第一个条件满足了，那么后面就不会在进行匹配。