scala – sbt / ivy无法解析文件系统解析器上的通配符常春藤依赖

发布时间：2020-12-16 18:48:47 所属栏目：安全来源：网络整理

导读：我使用?/ .sbt / repositories文件告诉sbt 0.13.5要从中检索哪些存储库.该文件只包含本地和一个file：//存储库,其自定义布局非常类似于标准sbt,并且表示了sbtVersion和 scalaVersion可选字段. 在解决我的项目的依赖关系时,我注意到了奇怪的行为：解决确切的

我使用?/ .sbt / repositories文件告诉sbt 0.13.5要从中检索哪些存储库.该文件只包含本地和一个file：//存储库,其自定义布局非常类似于标准sbt,并且表示了sbtVersion和 scalaVersion可选字段.

在解决我的项目的依赖关系时,我注意到了奇怪的行为：

>解决确切的依赖项工作正常
> latest.integration也很好
> x.y形式的通配符解析没有找到任何东西,而是似乎在寻找文字模式.我收到表格的错误：

    [warn] ==== myrepo: tried
    [warn]   file://path/to/my/repo/myorg/mypackage_2.10/[revision]/ivy-[revision].xml
    [info] Resolving myorg#mypackage_2.10;2.7.1.+ ...
    [warn]  module not found: myorg#mypackage_2.10;2.7.1.+

如您所见,明确提及repo布局模式.

我大部分时间都很困惑,因为除了通配符依赖项外,解析器的工作正常.我尝试在常春藤文档中查找某些解析器(如我正在使用的文件：//解析器)是否没有实现某种依赖解析,但这似乎不是一件事,所以我’我大多难过.知道我可以做些什么来使它工作,或者可能导致它的原因？

解决方法

我过去遇到了类似的问题.我们有一个或多个应用程序,我们将构建所??有使用相同的Ivy2缓存.如果我们在这些构建中使用通配符,我们有时会遇到无法正确解析依赖关系的情况.它只会在我们使用通配符时引起问题.其他一切都很好.

我们发现的问题是在某些情况下Ivy2 Cache会变得腐败.通常,解决方案是从Ivy2 Cache中删除有问题的库.然后,如果我们再次运行构建,它将工作.

我最终发现了一篇帖子,暗示Ivy2 Cache上的某些操作不是线程安全的. I.E.同时运行多个构建可能在某些情况下破坏缓存.我们最终为所有构建设置了自定义Ivy Cache文件夹.这解决了这个问题.

对不起,我找不到引导我走这条路的原始帖子,但下面的帖子可能有些相关.

https://groups.google.com/forum/#!topic/simple-build-tool/eCOkACPjm9E
https://groups.google.com/forum/#!topic/simple-build-tool/wFXhJcngy9Y

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!