使用常春藤更改常春藤中的默认存储库

Question

我有一个环境，其中（基本上）任何构建的所有依赖项都需要从我们的工件存储库中提取，同时许多第 3 方库需要从源代码构建（通常具有非常小的自动更改）并存储在存储库中以用作将来的依赖项。这样做的原因不在我的控制范围内，也无法更改。我正在寻找将这些第 3 方库从 github 或任何地方提取源代码后指向我们的存储库的最佳方法，从使用 ivy 的任何内容开始（并非所有内容都使用 ivy，至少也使用 maven 和 gradle，但 ivy被大量使用，所以从那里开始）。

我已经阅读了有关更改一个项目（Here 和其他站点）的默认存储库的常春藤选项的相当多的内容，但我想尝试做一个更广泛的解决方案，这可以节省大量时间从长远来看。我想到的一种选择是修改 ivysettings-public.xml 文件，以便默认的 ivy 公共存储库实际上是我们的工件。我看到的两个问题是，一个项目可能会设置一个特定的存储库以在默认的公共存储库之前进行检查，尽管我不知道这有多普遍。这也可能需要从源头构建常春藤？不是不可能完成的任务，只是额外的工作，尽管我再次不确定它是否会。但我很确定我知道（或很容易弄清楚）如何执行此解决方案所需的操作。

另一个可能的选择是让某种类型的模块或中间人附加到 ivy 并拦截存储库请求，将它们重定向到我们的工件。这个我实际上不确定它是否可能，但似乎它可能是。

我知道可能有一些环境变量或 ANT 属性可以在构建调用之前设置，它们也可能起作用（来自与以前相同的链接）。这不是很理想，但仍然比为每个项目更改 ivysettings.xml 文件要好得多。

基本上，这样做的最终目标是我们可以从 github 中提取一个使用 ivy 的项目，在不更改代码的情况下构建它，并让所有依赖项调用查看我们的工件存储库。这也可以通过使用 maven 或 gradle 等的东西来完成，但似乎一个适合所有解决方案的解决方案要么是不可能的，要么是更多的工作，然后它是值得的（虽然我总是错的），所以从常春藤开始。我觉得我的第一个想法是节省时间和可行性的最佳组合，但我知道的足以知道它可能有更好的选择。

Answer 1

您无需担心默认存储库。我看到在那个页面中，您链接的术语可能会让常春藤新手感到困惑。这些只是一些类型的存储库，但您无需担心。

您只需在 ivysettings.xml 中设置一个chained resolver。在该链接解析器中，您可以根据需要添加任意数量的（子）解析器，其中一个可以是您的工件，另一个可以是一些公共存储库（如 maven Central），第三个是一些用于测试的本地文件系统解析器等......无论何时使用ivy，告诉它使用这个链式解析器，或者将它设为 ivysettings 中的默认解析器。

当然，在发布您的 ivy 模块时，请确保使用其中一个子/子解析器，我猜您会使用指向您的工件中的 ivy 存储库。