【问题标题】:Using closed-source dependencies with Maven在 Maven 中使用闭源依赖项
【发布时间】:2011-06-24 22:42:24
【问题描述】:

我有一个想使用 Maven 构建的闭源项目。它依赖于两个 java 库,这些库在我能够找到的任何公共存储库中都不可用(在本例中为 libGoogleAnalytics.jar 和 FlurryAgent.jar,但该问题适用于任何闭源依赖项)。

我希望我组织中的任何人都能够使用与我用于构建应用程序的依赖项的完全相同版本来构建应用程序。这包括我的同事和我们的构建服务器。


如何管理 maven 不知道如何解决的闭源依赖项?

显然,我可以到每个人的机器上并手动执行“mvn install:install-file”以将二进制文件放入他们的 maven 存储库,但是像这样手动管理依赖项会破坏依赖项管理器的目的。

根据 maven 的 Internal Repositories 文档,我可以在某处设置存储库服务器并将二进制文件放在那里,然后所有开发人员都可以访问它。但这意味着我有一个新服务器要维护(或者至少在现有服务器上有一个新网站)。这也意味着我必须担心权限以确保外部各方无法访问存储库。这也意味着我现在必须担心备份和可用性,这样如果存储库不可用,开发人员就不会遇到问题。

如果我能以某种方式使用我们现有的 scm(在本例中为 hg,但它可能是 git 或 svn 或其他)来存储依赖项,那么所有这些问题对我来说都会消失。我们的源代码控制存储库已经备份,基本上始终可供进行构建的开发人员使用,并且已经处理了它的权限。

但我还没有弄清楚如何使用 hg 管理 maven 依赖项,如果这可能的话。

【问题讨论】:

  • 检查这个问题:stackoverflow.com/questions/2588502/… 我也有类似的问题。
  • 如果你正在构建一个商业产品,你应该有一个包含 all 依赖项的内部仓库,这样你的构建不依赖于外部源 - 你可以如果您的互联网连接中断,仍会创建构建。

标签: mercurial maven wagon


【解决方案1】:

事实证明,Manfred 的回答对我不太适用。该应用程序已编译,但由于缺少所需的谷歌分析类,它没有在我的 Android 设备上运行。

按照他提供的链接,我发现this solution 实际上更干净并且工作正常。

总之,我在 pom.xml 中添加了以下依赖项。 groupId、artifactId 和 version 都是我用合理的值组成的:

<dependencies>
    ...
    <dependency>
        <groupId>com.google.android.apps.analytics</groupId>
        <artifactId>libGoogleAnalytics</artifactId>
        <version>1.1</version>
    </dependency>
    <dependency>
        <groupId>com.flurry</groupId>
        <artifactId>FlurryAgent</artifactId>
        <version>1.24</version>
    </dependency>
</dependencies>

然后我添加了一个存储库定义,用于在我的项目的源代码树中存储第三方依赖项的位置:

    <repository>
        <id>third.party.closed.source.repo</id>
        <url>file://${basedir}/../maven_repo_3rd_party</url>
    </repository>

然后我将 jar 文件移动到以下位置:

./maven_repo_3rd_party/com/google/android/apps/analytics/libGoogleAnalytics/1.1/libGoogleAnalytics-1.1.jar
./maven_repo_3rd_party/com/flurry/FlurryAgent/1.24/FlurryAgent-1.24.jar

一旦我这样做了,我的项目编译和运行就好像第三方依赖项是从官方 maven 存储库中解析的一样。

【讨论】:

  • 我想知道如果您在目录结构中更深地添加模块,这是否有效。相对路径 ../maven_repo_3rd_party 似乎很脆弱。
  • 它适用于大多数 maven 项目。您只需要调整模块的相对路径即可。
【解决方案2】:

虽然我真的认为您应该使用专用的存储库服务器,而 Sean Patrick 对此完全正确,但这里有一个 hack 可以让它工作。

像过去一样将 jar 文件放在 libs 文件夹中(记住 Ant.. 哎哟).. 然后使用作用域系统和路径声明对每个 jar 的依赖关系。

这里描述了我可以这样做的一个例子

http://www.simpligility.com/2010/01/how-to-mavenize-a-typical-web-application-build-jasperserver-3-7-sample-webapp/

具体来说,一个依赖会例如看起来像这样

<dependency>
  <groupId>jasperreports</groupId>
  <artifactId>jasperreports-chart-themes</artifactId>
  <version>3.7.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/jasperreports-chart-themes-3.7.0.jar</systemPath>
</dependency

哦,现在我告诉了你怎么做,记住这是不好的做法,有很多问题,但它会起作用......

【讨论】:

  • Sean Patrick 完全正确“完全正确”让我投了反对票。我想这就是奥巴马的感受:-)
  • 但是为您的解决方案 +1 这可能比滥用 SCM 作为 maven repo 更好
  • 对不起肖恩!但这确实是我想要的更多。
  • @emmby 我不是在抱怨没有被投票。我在抱怨被否决。
  • 是的...当我知道我是对的并且其他人同意并且我无能为力时,有时我会被否决..
【解决方案3】:

使用专用的存储库服务器

根据 maven 的内部存储库 文档,我可以设置一个 存储库服务器某处并放置 那里的二进制文件,所有的 然后开发人员将访问。

没错。设置具有多个存储库的 maven 存储库服务器,例如这些:

  • internal-releases
  • internal-snapshots
  • external-opensource
  • external-closedsource(这就是我们所说的 lib 所在)

但这意味着我有一个新服务器 维护(或至少一个新网站 现有服务器)。这也意味着我有 担心权限,以确保 外部各方无法访问存储库。

是的,但是一家从事认真软件开发的公司应该拥有这样的基础架构。但是,如果您的公司对使用 Maven 很认真,那么可能还应该有一个专门的配置管理职位,这个人应该管理这个服务器。

这也意味着我必须担心 现在备份和可用性,以便 开发人员不会遇到打嗝,如果 存储库不可用。

标准存储库服务器(例如Sonatype Nexus)坚如磐石。如果它挂起,只需重新启动它正在运行的应用服务器/servlet 容器。此外,一旦开发人员从 repo 下载了一个库,它就会保留在本地 repo 中,所以即使 repo 关闭,也不应该有问题(但是当服务器关闭时,您不能引用新的依赖项) .


将现有的 SCM 用作 maven 存储库

好的,如果您真的想将 SCM 用作 maven 存储库,请按以下步骤操作:

http://maven-svn-wagon.googlecode.com/svn/site/index.html

本文介绍了如何为您自己的项目设置基于 SVN 的 maven 存储库。但是,如果您想将第三方部署到 repo,只需使用此处提到的配置创建一个 pom 并将该 pom 用于deploy:deploy-file您的库。

(也有其他 wagon / scm 实现,配置略有不同,但解决方案保持不变:根据您正在使用的 wagon 实现创建一个 pom,然后执行deploy:deploy-file(查看更多信息@ 987654324@)

【讨论】:

  • 谢谢,但正如我在描述中所说,我明确希望避免这种解决方案。我的公司并不“认真对待 maven”。我正在尝试在没有其他公司员工大力支持的项目上使用 maven,因此无法承担另一台服务器的维护开销。
  • @emmby 抱歉,这是唯一与 Maven 工作方式有关的方法。如果您不喜欢 maven 的工作方式,请不要使用 maven。当然,您也可以将 jar 与将其安装到用户本地服务器的 shell 脚本一起放在文件服务器上,但这不是当今软件开发的方式。构建应该是可重复的和独立于工作场所的。以Joel Test ferchrissakes 为例,如果您不按照上述(或类似方式)执行此操作,您至少违反了第 2 和第 3 项。
  • 感谢您的更新,肖恩。我在使用 mercurial 和 maven-scm-provider-hg 时遇到了很多问题,但幸运的是 Manfred 提出了一个适合我的解决方案。查看这些未解决的问题:jira.codehaus.org/browse/MNG-2227 和 maven.40175.n5.nabble.com/…
猜你喜欢
  • 2012-06-28
  • 2015-08-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-11-17
  • 1970-01-01
  • 2010-12-16
  • 2014-06-01
相关资源
最近更新 更多