我有一个环境，其中（基本上）所有构建的所有依赖项都需要从我们的工件库中提取，同时需要从源代码构建许多第三方库（通常只进行非常小的自动更改）并存储在存储库中将来用作依赖项。这样做的原因超出了我的控制范围，而不是可以改变的东西。我正在寻找将这些第三方库从github或任何地方拉出来之后将这些第三方库指向我们的存储库的最佳方式，从任何使用常春藤开始（不是所有东西都使用常春藤，至少使用maven和gradle，但是常春藤使用了很多，所以从那里开始）。
我已经阅读了一些关于更改一个项目（Here和其他网站）的默认存储库的常春藤选项，但是想尝试做一个可以节省很多的更广泛的解决方案从长远来看。我想到的一个选项是修改ivysettings-public.xml文件，因此默认的常春藤公共存储库实际上是我们的工具。我看到的两个问题是项目可能设置一个特定的存储库来检查默认的公共存储库，尽管我不知道它有多常见。这也许需要从源头建立常春藤？这不是一项不可能完成的任务，只是额外的工作，尽管我再也不确定它是否会赢或不会。但我非常确定我知道（或者很容易弄明白）如何做到这个解决方案所需要的东西。
另一种可能的选择是让某些类型的模块或中间人附加到常春藤并拦截存储库请求，将它们重定向到我们的工件。这个我不确定它是否可能，但它似乎可能是。
我知道在构建调用之前可能会设置一些环境变量或ANT属性，这些属性也可能起作用（来自之前的链接）。这并不理想，但仍然比为每个项目更改ivysettings.xml文件要好得多。
基本上，最终的目标是我们可以从使用常春藤的github中提取项目，在不更改代码的情况下构建它，并让所有依赖调用查看我们的工件库。这也可以通过使用maven或gradle等的东西完成，但似乎一个尺寸适合所有解决方案要么不可能，要么更多工作然后它值得（尽管我总是错的），所以从常春藤开始。我觉得我的第一个想法是节省时间和可行性的最佳组合，但我知道这足以让人知道它可能是更好的选择。
答案 0 :(得分：1)
您不需要打扰默认存储库。我看到，在那个页面中你链接了这个术语，对于常春藤新人来说可能会让人感到困惑。这些只是某些类型的存储库，但您无需担心。
您唯一需要做的就是在ivysettings.xml中设置chained resolver。在那个链式解析器中，您可以根据需要添加任意数量的（子）解析器，其中一个可以是您的神器，另一个是公共存储库（如maven central），第三个是用于测试的本地文件系统解析器等...每当您使用时常春藤，告诉它使用这个链式解析器，或者将它作为ivysettings中的默认解析器。
当然，在发布常春藤模块时，一定要使用其中一个子/子解析器，我猜你会用它指向你神器中的常春藤回购。