评论者：cemerick
SS 的观点是正确的，这种做法不会给 Maven 带来任何问题。此外，构建可以很容易地设置为总是生成两个jar包，一个“正常”，一个“调试”。
我建议，尽管 {{clojure.debug}} 可能会有广泛的影响，但还应提供额外的属性，以便对未来可能出现的每个“调试”相关参数化提供精细控制。
我想提出一些可能相关联的担忧（在思考了上面的断言后），这可能仅仅是我在某些领域的理解不足所导致。
在查看 {{assert}} 在 {{core.clj}} 中的使用情况（据我所知只有两个地方：验证 {{derive}} 的参数和检查 {{fn}} 的前/后条件），似乎不可取将其设置为 {{false}}。即非 {{Named}} 值能够进入层次结构，前/后条件将被简单地忽略。
我理解，断言（在这里指的是JVM结构，Clojure重用了{{AssertionError}}）不应该用于验证公开API函数的参数，也不应该用于验证函数正常操作的任何方面（即（链接：http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage 文本：“不使用断言的地方”")). 这意味着{{derive}}在必要时应该抛出{{IllegalArgumentException}}，而函数的前置和后置条件可能应该抛出{{IllegalStateException}}--或者无论如何，通过{{assert}}抛出不应该是{{AssertionError}}。这会与使用{{assert-args}}而不是{{assert}}的大多数核心函数匹配得更好，前者抛出的是{{IllegalArgumentException}}而不是{{AssertionError}}。
这让我提出了一个问题：{{assert}}（以及 * ）是不是Clojure构建的，还是一个准交互表单？
如果是前者，那么它大致可以具有我们想要的任何语义，但这样看来它似乎不应该抛出{{AssertionError}}。
如果是后者，那么在JVM上{{AssertionError}}是合适的，但我们需要注意断言可以在运行时启用和禁用（无需切换不同的Clojure构建），理想情况下使用宿主定义的开关（例如{{-ea}}及其朋友），而不太可能是类似 * 的东西。我不知道这在这个时候是否可行或实用（我猜想这需要相当大的编译器更改）。
希望以上的讨论还没有成为过眼云烟。提前感谢您的耐心。；-)
