有没有办法在 maven 尝试解决它们之前安装 maven 依赖项？

Posted 2023-02-25

【中文标题】有没有办法在 maven 尝试解决它们之前安装 maven 依赖项？

【英文标题】：Is there are way to install maven dependencies before maven attempts to resolve them?

【发布时间】：2011-08-22 13:26:43

【问题描述】：

我必须从远程位置解压缩一些依赖项并在本地安装它们。

我成功获取它们（使用 antrun 插件）并安装它们（使用安装插件）

但是，如果我将它们定义为依赖项 (<dependency>..</dependency>)，maven 首先会尝试解析它们，然后如果成功，则继续进行 antrun 并安装。

我也尝试了 build-helper-plugin 及其 attach-artifact，但它没有做任何事情（它甚至没有将工件添加到最终的 war 文件中）

那么，如何在 maven 尝试解决依赖关系之前运行我的执行？

【参考方案1】：

有趣的问题！一种尝试（也许）是使用多模块项目设置。

在父项目中获取并安装您的依赖项，并在子模块中使用它们。我这样测试了我的假设：

父 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.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>foo.bar</groupId>
    <artifactId>foo.bar.parent</artifactId>
    <version>1.0.0</version>
    <packaging>pom</packaging>

    <modules>
        <module>foo.bar.child</module>
    </modules>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>1.6</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <configuration>
                            <target>
                                <echo
                                    message="Hello world!" />
                            </target>
                        </configuration>
                        <goals>
                            <goal>run</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

模块 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.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>foo.bar</groupId>
    <artifactId>foo.bar.child</artifactId>
    <version>1.0.0</version>

    <parent>
        <groupId>foo.bar</groupId>
        <artifactId>foo.bar.parent</artifactId>
        <version>1.0.0</version>
    </parent>

    <dependencies>
        <dependency>
            <artifactId>can.not</artifactId>
            <groupId>find.me</groupId>
            <version>0.0.0</version>
        </dependency>
    </dependencies>

</project>

在子模块构建失败之前，我从父 pom 构建中获得了“Hello World”输出（因为缺少依赖项）。如果您实现在 parent.pom 的构建中提供依赖项，则子模块项目应该是可构建的。

【讨论】：

好主意。我明天试试（虽然它在其他简单的配置中引入了一些复杂性）

Maven 3.5.0 没有这种行为，总是先解决依赖关系。

想评论一下，它确实有效，但是如果您在dependencyManagement 中定义了一个依赖项，并且范围导入它首先解决了依赖项。

【参考方案2】：

您应该查看正在运行的 Artifact Repository Manager，例如 Archiva，然后您可以将它们加载到那里，然后在您的 ~/.m2/settings.xml 文件中添加您的 Archiva 服务器，而不必担心手动进行本地安装，即假设工件尚未在远程存储库中。如果您的“远程位置”是 Maven 存储库，Archiva 也可以透明地代理它。

【讨论】：

谢谢，我知道该选项，但预计该项目将是短暂的，并且设置存储库的组织工作不值得。 :)

当短期项目变成永不完全消亡的僵尸项目并且每个接触它的人都必须手动在本地添加依赖项时，从长远来看，它将为您节省工作量，然后您开始无法找到正确的项目，因为您的项目无法针对较新版本进行编译，我花了 5 分钟解压 Archiva 并开始向其中添加内容。自从我设置了依赖项后，我的开发人员曾经不得不在本地安装它。

我同意你的看法。但是我们需要有一个服务器，并且管理员可以查看它......并且对于不同的环境（和不同的构建）可能存在不同版本的依赖项，所以无论如何它都会变得更加复杂。不是我喜欢我所说的，而是为“可以用 ant 完成”的事情安排基础设施......你知道 ;)

我在我的团队控制的虚拟机上运行 Archiva，这样我们就可以用它做我们想做的事，我们所有的开发工具都在这个虚拟机上，我们的 IT 部门所做的就是确保虚拟机每晚都会备份。

我赞成你的回答，因为在大多数情况下这是正确的做法。但由于其他内部并发症，我采取了不同的做法。

【参考方案3】：

我最终分两个阶段进行：

设置 antrun 并安装执行以在 clean 上运行 选择package如果选择@ 987654322，如果尚未清洁一次，则构建将失败

该解决方案虽然引入了一些复杂性。

【参考方案4】：

你可以尝试依赖system范围并添加systemPath：

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.0</version>
    <scope>system</scope>
    <systemPath>$project.basedir/lib/myhackedjunit-4.0.jar</systemPath>
</dependency>

system 范围与provided 类似，只是您必须提供明确包含它的 JAR。工件始终可用，不会在存储库中查找。

systemPath 仅在依赖范围为系统时使用。路径必须是绝对的。由于假定系统范围依赖项是预先安装的，因此 Maven 不会检查项目的存储库，而是检查以确保文件存在。

【讨论】：

我这样做加上使用安装插件

不起作用，因为 maven 抱怨找不到 jar。

不应使用系统范围。