评论者：cemerick
SS 是正确的，这种方法对 Maven 来说不会引起任何问题。此外，构建可以轻松设置为始终生成两个 JAR 包，一个是“普通”的，一个是“调试”的。
我建议，尽管 clojure.debug 可能会有广泛的影响，但应该提供额外的属性，以便为可能在未来提供的每个额外的“调试”相关参数化提供精细的控制。
我想提出一些可能的相关关注点（在思考上面的断言之后），其中一些或所有这些可能是由于我在各个领域的理解不足造成的。
看在 core.clj 中的 assert 使用情况（据我所知只有两个地方：验证 derive 的参数和检查 fn 的预条件和后条件），似乎不智将它们默认设置为 false。即非 Named 值将能够进入层次结构，并且预条件和后条件将简单地被忽略。
据我所知，断言（这里指的是 JVM 构造，Clojure 是从其中重用 AssertionError 的）不应用于验证公共 API 函数的参数，或用于验证函数的正常操作的任何方面（即（链接：http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage 文本：在哪里不使用断言》）。这意味着当需要时，derive 应该抛出 IllegalArgumentException，而 fn 的预条件和后条件可能应该抛出 IllegalStateException — 或者至少通过 assert 抛出非 AssertionError。这将与 core 中大多数使用 assert-args 而不是 assert 的函数更为匹配，前者抛出 IllegalArgumentException 而不是 AssertionError。
这导致我提出一个问题：assert（和 * }）是 clojure 构造，还是准互操作形式？
如果是前者，那么它的大致语义可以是我们想要的任何语义，但似乎不应该抛出 {{AssertionError}}。
如果是后者，那么在JVM上抛出 {{AssertionError}} 是合适的，但我们需要注意在运行时可以进行断言的启用和禁用（无需切换不同的Clojure构建），理想情况下使用宿主定义的开关（例如 {{-ea}} 和同类）和很可能不是类似 * 这样的东西。我不太清楚目前这是否可行或实用（我想这需要显著的编译器更改）。
希望上面的内容现在还没有成为过去式。提前感谢您的耐心。 ;-)
