使用离线 clj 吗？

Question

我对一个离线 Clojure 项目有一个用例。我想包含一个捆绑的依赖关系（在这种情况下，是经过修改以离线工作而不会获取 js 依赖项的 Oz 版本）。结果是包含 Oz 所需所有内容的 uberjar。我想从 clj CLI 工具中操作它。我按照指南中的指示操作，并有一个与 uberjar 共置的最小 deps.edn

{:deps {metasoarous/oz {:local/root "./oz.jar"}}}

在我心中，这应该（在某种程度上）等同于调用
java -cp oz.jar clojure.main

在不更改 deps.edn 的任何额外更改的情况下，启动 clj 将尝试解决依赖关系（例如，对于 clojurescript），这我并不想（实际上，由于网络设置，它们会失败）。

是否有推荐的方法，可以将 uberjar 简单地视为本地依赖项，而不接触高级依赖关系解析机制？我希望利用 deps.edn 中的选项（例如，设置源路径等），只是预装了许多库到 uber.jar 中（假设在有限的环境中我所需要的所有依赖项）。

另一个选项（我想）是将它安装到本地的 .m2 中，将其视为 Maven 坐标，这应该（希望）防止 clj 尝试在线嗅探依赖项。
我希望本地 jar 方法能够工作。

Answer 1

目前 clj 没有离线模式，而且 jar 依赖被检查，jar 内部找到的 pom，并据此检索依赖项。我想如果你产生了一个没有内部 pom 的 uberjar，这可能足够了。

你为什么不直接这么做：java -cp oz.jar clojure.main呢？从我的了解来看，在这个场景下，clj 并未提供比这个更多的价值。

Comments

---

---

---

一旦将事物组合成一个uberjar，tools.deps就无法再对他们进行任何有用的操作，它们看起来就像一个巨大的工件。版本选择不起作用，类路径上的混合操作也不起作用等。别名用于修改依赖解析或类路径构造，但这些都被uberjar破坏。uberjar的整个目的就是没有其他东西。uberjar与所有依赖解析和类路径工具都是内在矛盾的，应该主要用于构建最终的应用程序jar并打包部署（永远不要将其放入Maven）。

---

所以另一种替代方案（我用lein做过）是维护一个本地.m2提前填充（例如从原始机器）包含所有依赖关系，并将其下载到隔离的盒子中。然后让正常的依赖关系解析机制启动，而不是通过一个不透明的uberjar包含一个大量的预解析依赖关系。这只是一种在气球中搬空气的方式 - 而不是打包一个单个的uberjar，你打包一个单的.m2存档，并符合tools.deps expectations。或者，安装uberjar本身作为.m2中的本地工件，并指向该文件（可能不被看好）。只要我在本地.m2中现有的预存在依赖关系宇宙内，或者使项目仅使用[本地库](https://clojure.org/guides/deps_and_cli#_using_local_libraries)， './tools.deps应该有效地在离线模式下工作，因为它首先从缓存中解析，对吗？不应该是这些东西强制deps尝试连接到clojars或maven，不是吗？

---

听起来你可能没有uberjar？如果你有，那么jar中不应该是所有东西都在了吗？因此它不会尝试拉进任何缺失的东西？