使用离线clj？

Question

我对一个离线clojure项目有一些使用案例。我想包含一个捆绑依赖项（在这种情况下是一个已经修改以离线工作的Oz版本，因此它不会检索JavaScript依赖项）。结果是包含了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检索依赖项。我想，如果你生产了一个没有内部pom的uberjar，这可能就足够了。

你为什么不直接使用java -cp oz.jar clojure.main呢？据我所知，在这种情况下，clj并没有提供任何额外的价值。

Comments

我曾希望理论上的价值是类路径管理，脚本等。管理源路径，利用别名等。基本上是最小的路径和（非Maven）依赖设置相关的事务（例如本地文件依赖，git依赖等）。我将转回到手动路径和依赖管理加脚本。

---

如果你使用的是uberjar，那么这些功能都不适用吗？

---

不在uberjar中的内容肯定适用。文件依赖、git相关、别名等。另外，不需要任何互联网连接，但实际上可以在一个相对隔离的盒子上通过本地解析链接。uberjar只是让oz在本地机器上解析依赖变得简单。我过去使用lein offline来做这件事，效果还可以（但仍有点笨拙）。当时clj似乎是一个更好的选择，因为它不需要将类路径生成、文件依赖、本地jar文件和可选加载结合到脚本和各种加载数据中。我还认为tools.deps可以简化这些操作。

---

一旦事物被合并到一个uberjar中，tools.deps就无法再对这些事物执行任何有用的操作 - 它看起来就像一个巨大的工件。版本选择不起作用，合并classpath上的资源不起作用等。别名用于修改依赖解析或classpath构建，但这些都被uberjars破坏了。uberjar的全部意义就在于没有任何其他东西。uberjar与所有依赖解析和classpath工具本质上存在矛盾，仅在构建最终部署的应用程序jar包时使用（并永远不要放入Maven）。

---

所以，我选择了另一种方案（我已经用lein做了）。即维护一个本地.m2预设文件，包含所有依赖项（例如，从原始机器），并将其下载到隔离的盒子中。然后，启动正常的依赖项解析机制，而不是通过一个不透明的uberjar包含大量预先解析的依赖项。这只是一种在气球中移动空气的方法 - 而不是打包一个uberjar，你打包一个单文件的.m2归档，并符合tools.deps的期望。或者，将uberjar本身作为本地工件安装到.m2中，并将deps指向它（也许有点不道德）。只要我保持在本地.m2中现有的依赖项的宇宙中，或者将项目限制为只使用[本地库](https://clojure.org/guides/deps_and_cli#_using_local_libraries)， tools.deps应该能够有效地在脱机模式下工作，因为它首先从缓存中进行解析，对吗？不应该有什么东西迫使deps尝试连接到clojars或maven，对吗？

---

听起来你可能没有uberjar？如果你有的话，jar中 wouldn't already have everything? 因此，它就不会试图加载任何丢失的东西？