如果我的开源项目是由maven管理的，并且依赖于不在maven仓库中的库？

想象一下这种情况。我有一个使用Maven管理的开源项目，它取决于知名库（例如jpathwatch）而不是Maven仓库。我怎样才能使它工作？如果我的开源项目是由maven管理的，并且依赖于不在maven仓库中的库？

直接的方法是将jpathwatch安装到本地maven存储库。然而，这给检查我的项目源代码并想由themselvz构建它们的人带来了负担。他们会遇到一个maven错误，然后查看README文件，或者放弃尝试。

有没有一种干净的方式让我工作呢？我必须回到ANT吗？

2013-01-21 Jian Chen

可能的重复[如何使我的maven项目取决于非maven项目？]（http://stackoverflow.com/questions/8025614/how-to-make-my-maven-project-depend-on-非Maven项目） –

我发现Maven是一个跛脚的技术，除非我也运行像Nexus这样的Maven仓库管理器。安装它，你永远不会回头看 –

我正在设计一个开源项目，我希望这个项目能够被不在我公司的人共享。虽然我可以在我的公司建立Nexus，但我不能认为其他人也会这样做。 –

您可以创建一个项目内存储库。

见Leonid Dubinsky's Blog - Maven in-project repository

来源

2013-01-21 09:57:52

对于需要' *'在他们的'〜/ .m2/settings.xml'中的人来说不适用（它应该是每个在Maven仓库管理器环境中工作的人） –

在网络上把JAR文件的地方，并引用它从该项目是微不足道的。您可以通过三个简单的步骤创建自己的Maven存储库，请参阅我的post。

来源

2013-01-21 09:59:11

Nooooooooooooo。 '系统'范围是邪恶的。使用'mvn install：install-file'或'mvn deploy：deploy-file'代替 –

ok，删除系统范围:) –

在这种情况下，你应该捆绑这个库到您的项目，并利用<system>依赖范围，就像这样：

<dependency> 
    <groupId>...</groupId> 
    <artifactId>...</artifactId> 
    <version>...</version> 
    <scope>system</scope> 
    <systemPath>${project.basedir}/lib/file.jar</systemPath> 
</dependency>

来源

2013-01-21 09:59:33

Nooooooooooooo。 '系统'范围是邪恶的。使用'mvn install：install-file'或者'mvn deploy：deploy-file'代替 –

@StephenConnolly我不认为'evil'是正确的词:)当然，最好不要使用它并拥有所有的依赖关系在存储库中，但我没有遇到任何其使用的副作用（除了你提到的传递依赖）之外。 –

而畸形的Manifest classpath是另一个重要的副作用......还有其他的，但我需要挖掘它们。假模块是比系统范围更好的解决方案 –

做到这一点，最彻底的方法是将库上传到中央（或做不到这一点，如果你的项目不是开源的，那么你的项目托管在Maven仓库中）。

有guide on uploading 3rd party artifacts to central详细说明如何发送项目不想要的上传工件。

还有一种可能性，就是在你自己的groupId下部署神器...更多的是最后的手段，或者如果官方的方式似乎对你来说太慢，则是第一种手段。

如果您想成为一名优秀的开源公民，请将这些内容上传到中央，以便其他人能够受益。

黑客喜欢in-project repositories不会为谁住企业的仓库管理器背后有<mirrorOf>*</mirrorOf>人工作的~/.m2/settings.xml（因为他们应该有）

像system范围黑客引起疼痛的永不落幕的世界，当人们尝试与项目一起作为传递依赖项...因为猜测${basedir}在从本地存储库而不是从反应堆解析项目时的结果是什么？尝试~/.m2/repository/your-groupId/your-artifactId/your-version这是肯定而不是你放第三方jar文件。

system范围攻击仅在您构建最终构件时起作用，即使这样它可能会产生意想不到的副作用（如将类路径烧入JAR清单中......这将是您的机器的磁盘路径...不是用户部署到路径）

只有三种解决方案：

将其部署到远程回购（偏爱去中心）
在本地仓库安装它（与所有的痛苦对于最终用户而言）
Fake模块解决方案（其中您假冒了一个JAR模块，并用您要分包的jar替换“built”jar，以便该模块现在是未构建的构建工件...这将最终成为选项1或2，但与“在项目存储库”中相比，这是一个不太恶劣的解决方案）

来源

2013-01-21 12:45:20

谢谢。似乎我必须让人们进行本地安装。 –

如果我的开源项目是由maven管理的，并且依赖于不在maven仓库中的库？

回答

相关问题