Maven实践（十二）---POM参考指南

最新推荐文章于 2025-05-30 18:39:29 发布

狮锅艺

最新推荐文章于 2025-05-30 18:39:29 发布

阅读量546

点赞数

分类专栏： Maven 文章标签： maven 开发人员解决方案

Maven 专栏收录该内容

15 篇文章

订阅专栏

什么是POM？

POM代表“项目对象模型”。它是一个名为pom.xml文件的Maven项目的XML表示形式。在使用Maven的人面前，说到一个项目是在哲学意义上说的，不仅仅只是收集包含代码的文件。一个项目包含配置文件，以及所涉及的开发人员所扮演的角色、缺陷跟踪系统、组织和许可证，项目的URL、项目的依赖关系以及所有其他包含在代码生命周期中的部分。这是一个关于项目的一站式解决方案。事实上，在Maven世界中，项目根本不需要包含任何代码，只是一个pom.xml。

概述

这是POM项目下的元素列表。请注意，modelVersion包含4.0.0。这是目前唯一支持Maven 2和3的POM版本，并且始终是必需的。

<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.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!-- The Basics -->     //基础部分
  <groupId>...</groupId>
  <artifactId>...</artifactId>
  <version>...</version>
  <packaging>...</packaging>
  <dependencies>...</dependencies>
  <parent>...</parent>
  <dependencyManagement>...</dependencyManagement>
  <modules>...</modules>
  <properties>...</properties>

  <!-- Build Settings -->   //构建设置
  <build>...</build>
  <reporting>...</reporting>

  <!-- More Project Information -->  //更多项目信息
  <name>...</name>
  <description>...</description>
  <url>...</url>
  <inceptionYear>...</inceptionYear>
  <licenses>...</licenses>
  <organization>...</organization>
  <developers>...</developers>
  <contributors>...</contributors>

  <!-- Environment Settings -->   //环境设置
  <issueManagement>...</issueManagement>
  <ciManagement>...</ciManagement>
  <mailingLists>...</mailingLists>
  <scm>...</scm>
  <prerequisites>...</prerequisites>
  <repositories>...</repositories>
  <pluginRepositories>...</pluginRepositories>
  <distributionManagement>...</distributionManagement>
  <profiles>...</profiles>
</project>

基础部分

POM包含有关项目的所有必要信息，以及在构建过程中要使用的插件的配置。它实际上是“谁”，“什么”和“哪里”的表现，而构建生命周期是“何时”和“如何”。这并不是说POM不会影响生命周期的流动。例如，通过配置maven-antrun-plugin，可以在POM中有效地嵌入ant task，这是一个声明。 build.xml会在运行（程序）时精确地告诉ant task 何时何地做什么，POM会声明其配置（声明式）。如果一些外部力量导致生命周期跳过ant插件执行，它将不会停止执行的插件做他们的工作。这与build.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.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.codehaus.mojo</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

Maven坐标

上面定义的POM是Maven 2和3将允许的最小值。 groupId：artifactId：version都是必需的字段（尽管如果从父进程继承，则不需要明确定义groupId和version）。这三个字段的行为非常类似于地址和时间戳。这标志着存储库中的一个特定位置，像Maven项目的坐标系一样。

groupId：这在组织或项目中通常是独一无二的。例如，所有核心的Maven工件（应该）应该在groupId
org.apache.maven下生成。组ID不一定使用点符号，例如junit项目。请注意，点注意的groupId不必与项目包含的包结构对应。然而，这是一个很好的做法。当存储在存储库中时，该组的作用与操作系统中的Java包装结构非常相似。这些点由操作系统特定的目录分隔符（例如Unix中的“/”）替换，从基础存储库成为相对目录结构。在给出的示例中，org.codehaus.mojo组存在于$M2_REPO / org / codehaus / mojo目录中。
artifactId：artifactId通常是该项目被称为的名称。虽然groupId很重要，但群组中的人很少会提及讨论中的groupId（它们通常都是相同的ID，例如Codehaus Mojo项目groupId：org.codehaus.mojo）。它与groupId一起创建一个将该项目与世界上其他项目分开的键（至少应该是:)）。除了groupId，artifactId完全定义了仓库中的工件的生存区。在上述项目的情况下，我的项目生活在$M2_REPO / org / codehaus / mojo / my-project中。
version：这是命名拼图的最后一块。groupId：artifactId表示单个项目，但它们不能描述我们正在讨论的该项目的化身。我们想要今天的junit：junit（版本4）还是四年前（版本2）？简而言之：代码更改，这些更改应该进行版本控制，并且该元素将这些版本保持一致。它也用于工件存储库中以将版本彼此分离。我的项目版本1.0文件存在于目录结构$M2_REPO / org / codehaus / mojo / my-project / 1.0中。

上面提到的三个要素指向一个项目的特定版本，让Maven知道我们正在处理的是什么，并且在其软件生命周期中我们想要它们。
packaging：现在我们有我们的地址结构groupId：artifactId：version，还有一个标准的标签给我们一个真正完整的地址。这就是项目的工件类型。在我们的例子中，上面定义的org.codehaus.mojo：my-project：1.0的例子POM将被打包成jar。我们可以通过宣布不同的包装使之成为一个war文件：

<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.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <packaging>war</packaging>
  ...
</project>

当没有声packaging，Maven假设工件是默认值：jar。有效的类型是组件角色
org.apache.maven.lifecycle.mapping.LifecycleMapping的Plexus角色提示（有关Plexus的更多信息，了解角色和角色提示的说明）。目前的核心包装价值是：pom，jar，maven-plugin，ejb，war，ear，rar，par。这些定义了针对特定包结构执行到每个相应构建生命周期阶段的默认目标列表。

您有时会看到Maven打印出一个项目坐标为groupId：artifactId：packaging：version。

classfier：您可能偶尔在坐标上找到第五个元素，也就是classifier。我们稍后会访问classifier，但现在只需知道这些项目就显示为groupId：artifactId：packaging：classifier：version。

POM关系

Maven的一个强大方面是处理项目关系; 其中包括依赖关系（和传递依赖项），继承和聚合（多模块项目）。依赖管理有一个很长的传统，是一个复杂的混乱，只是最微不足道的项目。随着依赖关系树变大而复杂，“Jarmageddon”迅速发生。 “Jar Hell”如下，其中一个系统上的依赖关系的版本不等同于通过错误的版本给出的版本，或者类似命名的jar之间的冲突版本。 Maven通过通用的本地存储库来解决这两个问题，从而正确链接项目，版本和所有。

Dependencies

POM的基石是其依赖列表。大多数项目都取决于他人建立和运行正确，如果所有的Maven都为您管理这个列表，您就获得了很多。 Maven下载并链接您的依赖关系，编译和其他需要它们的目标。作为一个额外的好处，Maven引入了这些依赖关系（传递性依赖）的依赖，允许您的列表仅专注于项目所需的依赖关系。

<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.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.0</version>
      <type>jar</type>
      <scope>test</scope>
      <optional>true</optional>
    </dependency>
    ...
  </dependencies>
  ...
</project>

groupId，artifactId，version：
你会经常看到这些元素。该三位一体用于及时计算具体项目的Maven坐标，将其作为该项目的依赖关系。此计算的目的是选择一个与所有依赖关系声明相匹配的版本（由于传递性依赖关系，同一组件可能有多个依赖关系声明）。值应该是：

groupId，artifactId：直接依赖相应的坐标
version：依赖关系版本要求规范，用于计算依赖关系的有效版本

由于依赖关系是由Maven坐标描述的，所以您可能会想：“这意味着我的项目只能依赖于Maven组件！”答案是，“当然，但这是件好事。”这迫使您完全依赖于Maven可以管理的依赖关系。有时候，不幸的是，当一个项目无法从Maven中央库中下载时。例如，项目可能依赖于具有封闭源许可证的jar，该jar禁止它在中央存储库中。处理这种情况有三种方法。

1、使用安装插件本地安装依赖关系。该方法是最简单的推荐方法。例如：

mvn install：install-file -Dfile=non-maven-proj.jar -DgroupId = some.group -DartifactId =non-maven-proj -Dversion = 1 -Dpackaging = jar

请注意，仍然需要一个地址，只有这一次您使用命令行，安装插件将为您创建一个给定地址的POM

2、创建自己的存储库并将其部署在那里。这对于拥有内部网的公司来说是一个最受欢迎的方法，需要使每个人都能同步。有一个名为deploy：deploy-file的Maven目标类似于install：install-file目标

3、将依赖关系范围设置为系统并定义systemPath。但是不建议这样做