Maven 3.0 的“mvn release:perform”不喜欢不在其 git repo 根目录中的 pom.xml

Posted 2023-03-30

【中文标题】Maven 3.0 的“mvn release:perform”不喜欢不在其 git repo 根目录中的 pom.xml

【英文标题】：Maven 3.0's "mvn release:perform" doesn't like a pom.xml that isn't in its git repo's root directory

【发布时间】：2012-05-28 11:28:37

【问题描述】：

我有一个关于 Maven、maven-release-plugin、git 集成、pom.xml 以及在 repo 本地副本的子目录中而不是在根目录中的 pom.xml 的问题。

设置如下：

我有一个私人仓库数量有限的 github 帐户 我想（正在学习）使用 Maven 来组织我的构建/发布 我可能需要创建许多 Maven“项目”，每个 git 存储库有几个项目 每个 maven 项目都需要一个“pom.xml”来定义其特征 我不能，或者至少不方便，将所有项目 pom.xml 文件放在 git 存储库的根目录中 所以我最终得到了这个项目的文件夹布局： git_repo_root_dir

project_A

文件夹 pom.xml 其他代码

project_B

文件夹 pom.xml 其他代码

等

... 我可以成功进入目录 git_repo_root_dir/project_A 并执行“mvn release:prepare” 我在 git_repo_root_dir/project_A 中的这一步失败：“mvn release:perform” 问题似乎是 git-tagged 代码已成功签出到 git_repo_root_dir/project_A/target/checkout/project_A 以准备发布构建，但在签出后“maven-release”插件进入目录git_repo_root_dir/project_A/target/checkout/。而不是 git_repo_root_dir/project_A/target/checkout/project_A/。进行实际构建，并且没有办法告诉“maven-release”插件在尝试弄乱 pom.xml 之前进入源的特殊标记副本的子目录 问题：有没有办法解决这个问题？是否可以选择以某种方式告诉“mvn release:perform”转到子目录？

这是我在此过程中遇到的实际错误：

[INFO] --- maven-release-plugin:2.0:perform (default-cli) @ standard_parent_project ---
[INFO] Checking out the project to perform the release ...
[INFO] Executing: /bin/sh -c cd "/Users/___/DEV c8ion 01/maven_based_code/0maven/standard_parent_project/target" && git clone [e-mail]:clarafaction/0maven.git '/Users/___/DEV c8ion 01/maven_based_code/0maven/standard_parent_project/target/checkout'
...
/* note, the pom.xml the build should go out of at this point is at
   '/Users/___/DEV c8ion 01/maven_based_code/0maven/standard_parent_project/target/checkout/standard_parent_project/pom.xml'
*/
...
[INFO] [ERROR] The goal you specified requires a project to execute but
    there is no POM in this directory
    (/Users/___/DEV c8ion 01/maven_based_code/0maven/standard_parent_project/target/checkout).
    Please verify you invoked Maven from the correct directory. -> [Help 1]

谢谢。

【参考方案1】：

这应该可以解决问题：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.3.2</version>
    <executions>
        <execution>
            <id>default</id>
            <goals>
                <goal>perform</goal>
            </goals>
            <configuration>
                <pomFileName>your_path/your_pom.xml</pomFileName>
            </configuration>
        </execution>
    </executions>
</plugin>

【讨论】：

所以我们必须在 pom.xml 文件中写入来告诉 Maven 在哪里可以找到相同的 pom.xml？嗯……

【参考方案2】：

您可以像通常tell Maven to run from a POM that's somewhere else 一样执行此操作：-f 选项。 mvn --help 如此描述：

-f,--file <arg>    Force the use of an alternate POM
                   file.

要在发布中执行此操作，您只需将适当的选项传递给发布插件。您可以使用perform goal's "arguments" property 来执行此操作。这个属性只是告诉发布插件一些额外的参数附加到它在发布时运行的mvn 命令。您可以通过在命令行中附加-D arguments="-f path/to/pom" 来设置它，或者在发布插件配置中的 pom 中永久设置它，类似于

<plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.3</version>
    <configuration>
        <arguments>-f path/to/pom</arguments>
    </configuration>
</plugin>

【讨论】：

感谢您的提示。我很快就会尝试这个，但还有一个问题：链接可以是相对的，即，当发布插件尝试使用代码的签出标记版本运行 Maven 时，当前目录是 .../project_A/target/checkout，但是POM 位于.../project_A/target/checkout/project_A/pom.xml，那么使用<arguments>-f ./project_A/pom.xml</arguments> 会起作用吗？

（顺便说一句：我要编译的第一个“项目”是“我将用于所有其他项目的标准父 pom.xml。它将被所有其他项目继承所有 git 存储库。）无论如何，一旦我运行“mvn 版本：显示插件更新”并明确列出所有插件，然后清理项目，然后执行“mvn 发布：准备”和“mvn 发布：执行”，即使不需要您的提示，构建也可以按预期工作-显然我使用的是各种插件的旧版本-显然，较新的版本很好地解决了这种情况。谢谢！

是的，./project_A/pom.ml 或 project_A/pom.xml 都可以。你显然已经知道继承。您可能还会发现聚合很有用。我最近answered another question on this topic.

值得注意的是，这在 maven 发布插件的早期版本中不起作用。我用 2.3.2 对此进行了测试，但没有成功。但是，它在 2.5.3 上运行良好。

【参考方案3】：

首先要了解 git，它的约定是每个项目都有自己的存储库。接下来的事情是 Maven 有它的约定，将 pom.xml 放到它的项目的根目录中是最明显的。此外，您正试图与 Maven 对抗，我预测您将输掉这场战斗，让您的生活变得不轻松。 如果你的项目 A 和 B 在某种程度上是相关的（相同的版本号或相同的发布时间），你应该考虑一个多模块构建，它会产生这样的结构：

root (Git Repos)
  +-- pom.xml
       +--- projectA (pom.xml)
       +--- projectB (pom.xml)

您可以从根目录一步完成 projectA（最好称其为模块）和模块 b 的发布。

【讨论】：

这种设置有一些用例，例如如果您有一个由许多不同服务组成的分布式系统。将它们全部放在同一个 repo 中允许跨服务进行一次提交。但是您不必一次全部发布它们，因为它们都有一个新版本号，这可能会迫使您更新您没有接触过的服务。