1

我们的组织目前使用一种被破解的 Java 依赖管理形式，有效地依赖于 IDE 配置，然后维护可以检出的这些配置的存储库。我们有多种依赖关系；其中一些是来自第三方的 .jar，而另一些是内部开发的项目（用 Eclipse 用语）或模块（用 IntelliJ 用语）。我们没有交付给的“客户”，也没有开源社区（我们是研究实验室），因此我们通常不会生成任何工作的二进制文件。基本上，我们所有的内部代码总是从源头工作。但是，这会带来一些问题：

  1. 这不会转化为我们的 CI 服务器，这意味着我们还必须维护一个 Ant 脚本存储库，以识别类路径上的源依赖项，以便 Bamboo 能够正确构建。这很烦人。
  2. 此方法不是跨 IDE；我们的一些开发人员更喜欢 Eclipse，而其他开发人员更喜欢 IntelliJ IDEA。如果通过让我们的开发人员选择他们选择的环境来提高他们的工作效率，我们不想妨碍这一点。
  3. 这种方法本身就很脆弱。如果有人创建了一个新项目，那么我们必须花费大量时间摆弄 Bamboo 的 Ant 脚本并重新导出我们的 IDE 配置。

我想让我们的研究人员转向更软件工程师的方法，例如自动构建/依赖管理，这将允许 IDE 和我们的 CI 设置之间的可移植性，但从我阅读 Maven 和 Ivy 的教程来看（还没有花太多时间看其他工具）一般的想法是定义二进制依赖项，带有选项将源代码拉到您的 .m2 或 .ivy2 中作为额外的，但不是作为依赖管理的唯一方法。理想情况下，我们将能够使用其中一个工具来处理来自第三方的二进制依赖关系以及我们的内部源依赖关系，方法是指向我们的内部版本控制。现有工具可以做到这一点，还是有一个我不知道的工具可以做到这一点？

编辑

也许更好的方式来说明我正在寻找的东西不仅仅是为了触发构建的依赖管理，而且在初始化一个新的开发环境时管理依赖。查看项目 A，您的依赖管理器会检查所有相关的本地源和第三方 .jar；在 Java 中，这与构建并没有那么远，因为大多数 IDE 都是围绕类路径/依赖项管理的有效 GUI，并带有一个花哨的文本编辑器，所以我认为这个请求并没有那么牵强，但我可能没有想到关于它已经够难了。

4

2 回答 2

1

我很确定这个答案是不完整的......

这是真正的 maven 和 ivy，每个人（gradle、sbt、rake）都基于二进制依赖项——因为通常会基于 jar 文件而不是源文件来运行应用程序。

此外，您可以生成源 jar 以允许其他人查看您的工作 - 正如您所说，这对于公共项目更重要，而不是仅对内部项目重要。所以我建议总是生成源 jars。所以它们将被归档在一个 Maven 存储库中。

好消息：这并不重要。我认为混淆来自于使用的 IDE 和构建工具之间的责任。为了简化持续集成，您需要将 IDE 排除在计算之外，并将构建仅基于构建工具。然后，IDE 将从构建工具配置中提取所需的信息并配置您的项目。这就是为什么在 IDE 中对构建系统的支持如此重要的原因。

我认为这里可能存在的问题是您在 IDE 中组合在一起的多个源存储库（SVN、Git 等）中有多个项目。我认为那不太好（如果它是真的）。Maven 确实维护了有关项目来源的信息。所以理论上你可以签出一个，然后检索它的依赖项并检查那些项目。但这听起来像一个 Eclipse / Maven 插件。

在 IDE 中，集成将确定您是否打开了与依赖项匹配的项目（基于 groupdId、artifactId、版本 - GAV 坐标）并从那里解析源而不是从远程存储库加载它们。

我认为唯一更大的变化是如何将初始项目导入 IDE？也许您可以提取每天都不会更改的模块并将它们视为标准依赖项。这加快了构建速度并提高了构建的稳定性。

嗯。希望这确实有所帮助:)

于 2013-09-04T15:22:31.710 回答
0

我不认为 maven 更喜欢二进制文件而不是源代码。这种认知是基于什么？据我所知，当您通过 maven 源插件构建一个源 jar 时，它将创建一个“附加工件”。当构建通过部署阶段运行时，该工件将部署到 Nexus（或您正在使用的任何存储库）。通常，它将位于类文件的 jar 旁边。它们都是 Maven 工件，可以在其他构建中作为依赖项相互独立地引用。区分两者的关键是第四个maven坐标，“分类器”。

除非我遗漏了什么，否则这将符合您的目的。. .

于 2013-09-04T18:58:23.147 回答