使用像Ivy或Maven这样的工具，是否可以识别仅作为源的依赖项？

Question

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

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

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

修改

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

Answer 1

我确信这个答案不完整......

真的是maven和ivy，每个人（gradle，sbt，rake）都基于二进制依赖 - 因为人们通常会根据jar文件而不是源代码来运行应用程序。

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

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

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

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

我认为唯一更大的变化是如何将初始项目导入IDE？也许你能够将每天没有改变的模块提取出来并将它们视为标准依赖关系。这样可以加快构建速度并提高构建的稳定性。

Hmmmm。希望在某种程度上有所帮助：）

Answer 2

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

除非我遗漏了某些内容，否则这将符合您的目的。 。