在Maven生命周期内安装第三方JARs与系统作用域依赖关系

Question

我的项目依赖于某些第三方JAR，这些JAR在Maven Central中不可用。

我看到关于这种情况的大部分信息，包括官方Maven Guide to installing 3rd party JARs，建议使用mvn install:install-file ...将工件安装到本地存储库中。这在当地开发时效果很好，但是当构建需要以自动化方式在许多不同的系统上执行时，需要这种手动步骤是不理想和不切实际的。

经常提出的另一个解决方案是将依赖项安装到组织范围的存储库中，但是在某些情况下这是不可能的。

既没有这些选项是可以接受的，我能想到的两个选项：

1. 存放在项目中的lib目录的JAR，并宣布了system范围的依赖（如severalanswers建议） 。这似乎适用于任何系统，因为依赖项与项目捆绑在一起，但我认为使用system是不好的做法（通常没有更多的解释）。
2. 将maven-install-plugin绑定到initialize生命周期阶段以将工件安装到本地存储库。但是，正如here所指出的那样，这会导致不必要的开销，因为它会针对每个构建版本运行。如果只有在没有安装神器时才有办法执行此操作，那可能是理想的。

我想要一个标准的Maven项目，可以使用常规的Maven生命周期来构建，而不需要任何带外的“运行脚本/初始化依赖关系”的步骤。

什么是最好的前进方向？

Answer 1

下面是最近这个问题的答案：Maven: keeping dependent jars in project version control

我不推荐使用安装文件中的生命周期。正如你所提到的，它会每次运行 - 上述解决方案将很快跳过项目。虽然上面创建了一个新模块，但它确实减少了许多JAR所需的冗长度，允许您使用可轻松复制到资源库管理器中的资源库格式，并将其保留在主版本之外。

我也不建议使用系统范围的原因提到一些问题，你链接到列表的答案。

Answer 2

我会创建一个ant任务来检查.mylibisinstalled文件。如果它不存在，mvn安装yourlib.jar并创建它。

然后，您可以将此ant任务与maven的初始化阶段相关联 - 开销很小。

这有点冒失，但你确实有一些限制。

Answer 3

如果有一种方法只有在未安装神器 时才会执行此操作，那可能是理想的。

即使知道它的内在丑陋，我也会直接回答你的问题。我一直在使用一个成功的解决方法配方，但要警告我个人认为这不比系统依赖关系更好。 Maven认为滥用配置文件是一种不好的做法。

创建一个单独的profile来安装库并绑定maven-install-plugin，如问题中所建议的。

您可以使用-P myprofile手动激活配置文件。 另一种选择，如果你想100％hackish，正在适应@vlf“检查文件”建议纯Maven。只需使用激活触发器的配置文件。 也许这样的事情（警告：未经）：

<activation> 
    <file> 
    <missing>${user.home}/.myapp/.mylibisinstalled</missing> 
    </file> 
</activation> 

如果你有一个共同的一套由许多项目使用的库，只需创建一个单独的安装神器与它自己的pom.xml。这样你就不需要为多个项目携带相同的jar文件。

我个人有一个install-extra-libs神器有此目的。它在lib文件夹中有一些jar文件（还有一些javadocs和源代码），一些依赖用于隐藏/密码保护的存储库，甚至直接使用antrun:run和ANT get task下载一些文件。对于lib文件夹和下载的罐子，出价有一些大规模的install-file。这是丑陋的和黑客，但通常需要一遍又一遍地将同一组库/ javadoc安装到多个存储库时才起作用。

优点：

• 所有两轮牛车发生这件神器内。我的项目使用干净的依赖语法。
• 没有jar文件重复。 SCM中没有JAR文件。
• 我认为这是一种“即时”创建新Maven存储库的方法。

缺点：

• 它违背了Maven的目的。如果您发现自己在为公共开源项目做这件事，请考虑将其上传到公共存储库并与Maven Central同步......以下是一个guide，解释如何从Sonatype存储库执行此操作。这需要一些时间，但至少其他人可能会从你的努力中受益。
• 它击败了Maven的目的x2。如果您不小心，很快就会失去Central Repository上的哪些依赖关系。我的大部分项目都使用一个或多个自定义安装的依赖关系，这使得任何公开都会很痛苦。

干杯，