maven - 从Maven中的POM文件读取属性文件

Question

为什么这不起作用？如何从属性文件中选择版本号。

在pom.xml中读取属性

<project>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
          </execution>
          <configuration>
            <files>
              <file>dev.properties</file>
            </files>
          </configuration>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

在dev.properties中

org.aspectj.aspectjrt.version = 1.6.11

pom.xml中的依赖性

        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${org.aspectj.aspectjrt.version}</version>
        </dependency>

错误:依赖项必须是有效版本

Answer 1

从命令行启动Maven时，它会经历多个阶段。这是对这些阶段的伪描述，我有意简化确切的顺序(可能会说出一些稍微不正确/乱序的风险)，以便您了解尝试执行的操作为何不起作用。

首先，它解析您的命令行，使用-Dname=value在命令行上定义的任何属性都将被注入(inject)MavenSession

检查反应堆定义命令行选项，以决定应构建的项目列表(也称为反应堆)。 -N表示仅构建根pom.xml，-pl允许指定要构建的模块列表，-am和-amd允许分别从-pl指定的模块添加上游或下游模块。目前，Maven尚未解析任何pom.xml文件。

解析-P配置文件激活规则以查看要激活的配置文件。

现在Maven具有足够的知识来开始解析pom.xml文件。首先从加载并解析根pom.xml(即当前目录中的根pom.xml)开始(或者，如果您使用-f指定了另一个<modules>，则选择该根)。最初的解析只是专注于确定要构建的项目列表。仅考虑了概要文件激活，因为它可能会影响可用的pom.xml列表。 pom.xml中的“组ID”，“ Artifact ID”，“版本”和“包装”坐标不能包含属性，因为此时尚未对pom.xml中的属性进行解析。 (细心的读者还将看到，这也解释了为什么您不能基于pom.xml中的属性来激活配置文件，因为在此阶段仅解析了系统属性)

一旦验证了项目集，Maven现在将对这些<properties>文件进行更多解析，以构建构建扩展列表(如果有)和插件列表。在此阶段，解析需要评估每个项目中的/project/build/extensions，因此这是对它们进行评估并将其“注入(inject)”有效模型的时候。因此，您可以使用系统属性和pom属性来定义(xpath)/project/build/pluginManagement/plugins/plugin，/project/build/pluginManagement/plugins/plugin/dependencies，/project/build/plugins/plugin，/project/build/plugins/plugin/dependencies和pom.xml中的坐标和其他依赖项。

现在，Maven开始解析在命令行上指定的目标和阶段的列表。对部分指定的目标进行评估，以与插件列表进行匹配。对于要针对其执行插件目标的所有项目，该匹配项必须是唯一的(即，如果它是一个聚合器目标，则仅在根目录中才需要进行匹配，但是对于所有其他“常规”目标，插件的简称必须为所有项目都使用相同的插件)。生命周期阶段必须来自默认生命周期之一，或者来自构建扩展中定义的生命周期。

从解析的目标和阶段列表中，Maven构造了构建计划，即它将在哪些项目上以什么顺序进行。为此，Maven必须解析反应堆项目/project/dependencyManagement/dependencies/dependency文件中定义的项目依赖项列表。这是因为反应堆内的另一个项目可能会产生依赖性，从而迫使对项目执行进行排序。因此，您可以使用系统属性和pom属性来定义(xpath)/project/dependencies/dependency和initialize中的坐标和其他依赖关系，但是请注意，此时尚未执行任何插件。

现在Maven有了构建计划，它开始按照其构建顺序遵循该计划。如果CLI上的第一个目标/阶段是目标，则将调用该目标。如果第一个目标/阶段是默认构建生命周期中的一个阶段，则Maven将以initialize阶段开始并执行绑定(bind)到该阶段的所有插件...以类似的方式沿阶段列表然后是列表继续项目。还要注意，clean package foo:bar site阶段仅作为默认构建生命周期的一部分执行。它不会在默认的清理或默认站点生命周期上执行，也不在任何自定义生命周期上执行。 (细心的读者将得出结论，这突出了该问题正在尝试的技术的另一个问题)。注意:请记住，聚合器目标在反应堆中形成“中断”，因此，如果您要求Maven运行foo:bar(其中clean package是聚合器mojo目标)，则foo:bar将针对反应堆中的所有项目运行，然后site将针对根目录运行，然后pom.xml将针对反应堆中的所有项目运行。换句话说，构建计划将采用最长的非聚合器目标和阶段的连续运行，再除以聚合器目标的最长连续运行。

在调用每个mojo(即绑定(bind)到某个阶段或直接从命令行指定的目标)之前，Maven会针对该mojo的有效<configuration>评估MavenSession。此时，Maven可以使用系统属性，在pom中指定的属性以及由先前执行的mojos注入(inject)<configuration>的任何属性。因此/project/build/directory可以引用任何这些属性...

除了

现在有一个警告...如果您说将(xpath)${some-property-i-will-set-via-a-mojo}设置为<configuration>，然后从/project/build/directory引用它，那么可悲的消息是(xpath)pom.xml在任何插件执行之前都会被评估为有效的${project.build.directory}，因此${some-property-i-will-set-via-a-mojo}将被赋予文字值java.io.File，并且在MavenProject中类型为new File(project.getBaseDir(),"${some-property-i-will-set-via-a-mojo}")，因此您实际发生的是<configuration>。如果您要注入(inject)的File字段的类型为<configuration>，则不需要类型转换，因此将直接注入(inject)该值，并且不会进行任何属性替换。

还有其他一些极端情况，例如上面概述的情况，但通常，属性替换将与/project/(parent/)?/(groupId|artifactId|version|packaging)部分中的“mojo注入(inject)”属性(例如Mojo's Properties Maven Plugin提供的属性)一起使用。在这些部分之外，它将不起作用。

因此，这是Stephen对于不同属性类型的快速经验法则:

系统属性

这些方法无处不在...但是在 ${...}中非常危险，因为您无法控制将项目作为传递依赖项引入时将定义哪些系统属性。在 /project/(parent/)?/(groupId|artifactId|version|packaging)中使用 pom.xml扩展应该被认为等同于以200kph的速度驾驶汽车，该汽车具有从方向盘上伸出的30cm(12英寸)金属钉，代替了安全气囊……哦，没有安全带……您我只喝了10单位酒精和两行可卡因。

settings.xml属性(和 /project/(parent/)?/(groupId|artifactId|version|packaging)属性)

这些在大多数地方都可以使用，但是在 <configuration>中永远不可用(因为在评估这些字段时尚未解析它们)，也不能用于考虑 Activity 配置文件(同样，在评估配置文件激活时也没有对其进行解析) )

Mojo注入(inject)的属性

这些可以在 String部分中工作，并且(由于注入(inject)的Mojo <configuration>参数的递归插值)在间接使用时可能会起作用，但是鉴于所涉及的不确定性，建议将它们的使用仅限于插件和报告的 .properties部分。

最后一件事

考虑将您的项目列为依赖项时会发生什么。如果您通过使用mojo从磁盘上的 pom.xml文件中提取依赖关系来指定其依赖关系，则当从Maven存储库中提取依赖关系时，Maven无法复制该依赖关系。因此，Maven将无法确定依赖性。因此它永远无法工作。

您可以做的是使用外部系统(例如ANT)从模板生成ojit_code，并将版本替换为该文件。然后使用实例化的模板进行构建。