deps清单依赖不尊重依赖项目中冒号：mvn/repos

Question

问题

如果一个项目使用自定义Maven仓库，则无法依赖基于deps.edn的项目（通过git或本地依赖）。尝试为依赖于此类项目的项目构建类路径将失败。

重复

我创建了一个展示这一问题的最小化仓库： https://github.com/vlaaad/deps-mvn-repos-repro

它包含3个deps.edn项目：lib、app-local和app-git。

lib 包含一个定义了自定义Maven仓库和从该仓库拉取依赖项的单个deps.edn文件。

app-local 包含一个定义了本地根依赖关系lib的单个deps.edn文件。

app-git 包含一个定义了git/url依赖关系lib的单个deps.edn文件。

预期行为

在lib、app-local和app-git项目中运行clj -P应成功。

实际行为

在lib项目中运行clj -P成功，但在app-local和app-git项目中运行失败，错误为“错误构建类路径。无法在中央仓库中找到artifact net.sf.saxon:saxon-dom:jar:9.1.0.8 (https://repo1.maven.org/maven2/)”

Answer 1

我的理解是这样的，这是出于设计目的，为了安全考虑，因此您不必依赖某些项目，而该项目会随机劫持依赖项来源的位置：您应该能够控制所有依赖项来自哪些存储库。

如果您依赖的东西反过来又依赖于来自非标准仓库的东西，这是由您自己决定的，您是否认为这是安全的；如果是，请按照适当的顺序明确地将该仓库添加到您的自己的deps.edn中。

这是我对此的看法。我很想听官方的回答。

Comments

目前我们的看法正是如此，但可能会发生变化。

与https://clojure.atlassian.net/browse/TDEPS-46存在相同的概念性问题

---

我当然不希望那个Maven仓库覆盖我的依赖项，但抽取那些不在central/clojars中的依赖项将是受欢迎的...

---

当然，出于安全考虑，不应该自动这样做。但是，工具可以提供低风险的地方来帮助遍历依赖项树并列出它们试图添加的Maven仓库，以及可能正在尝试这样做的依赖项。

---

也许这可以作为每个单独的依赖项的选项，因为有些合法的使用案例需要。

我会给你一个具体的例子

在Metabase中，我们的Amazon Redshift扩展作为单独的`:local/root`子项目；Amazon有它自己的Redshift JDBC驱动程序的repo。理想情况下，我们只需要在子项目中设置自定义的`:mvn/repos`，然后在我们包含它时将其拉入主项目。目前，我们必须复制repo路径并在两个地方指定`:mvn/repos`。

类似于以下内容：

```
{:extra-deps
 {metabase/redshift {:local/root "modules/drivers/redshift", :mvn/include-repos true}}}
```

我认为应该是可行的。