如何避免clojure源文件的可传递AOT编译

我有一个跨Java的clojure项目，它使用maven作为构建工具。需要对某些名称空间进行AOT编译

问题是，编译需要很长时间才能完成。检查maven过程可得出以下观察结果：

编译时，CPU等待时间非常长（单核70-90%）

对该高等待线程进行采样会得到一个堆栈，其中最内部的调用是：

at java.io.FileDescriptor.sync(Native Method)
at clojure.lang.Compiler.writeClassFile(Compiler.java:7269)

检查

target/classes/

文件夹，会生成大量

.class

文件，主要用于我的项目所依赖的基于clojure的库

我所尝试的：

指示clojure maven插件只编译给定的名称空间。但是，沿着依赖关系线的传播没有受到抑制

显式包含给定的名称空间，并排除依赖项的名称空间。依赖项库仍然由AOT进程重新编译

嗯，就在我按下“POST”按钮之前，我发现了这个。看起来5年前我们就有过这样的讨论，而这个问题并不是clojure maven插件所特有的。那么这个问题有什么新鲜事？在我的机器上进行一次

mvn clean编译

大约需要4分钟，我的项目规模不大，我可以随便喝杯咖啡，坐下来放松一下

---

如果这个问题在不久的将来不能以任何方式得到解决，有什么建议可以减轻我的痛苦？任何想法都是受欢迎的。

事实证明，这个问题可能还没有一个好的解决方案。然而，我现在求助于这种四处走动的方式：

我现在不再运行clean目标，而是使用自己的

clean.sh

脚本只清理自己名称空间中的类文件。通过这样做，我的4分钟编译时间下降到1分钟多一点

---

我会把这个问题留待讨论，也许有一天我们会找到更好的解决方案。

只做“maven安装”怎么样？@dAni注意事项在干净的部分。只要清除编译的类文件，编译就会重新开始。虽然增量编译是可能的，但我们确实需要不时地清理它。Clojure 1.8今天发布了。在我的一些项目中，我看到编译时间缩短了33%。@dAni好极了！这看起来确实是一个关键的性能提升。我将尝试一下并尽快报告。选择1.8后，我的

mvn clean compile

现在只花了40多秒！从4分钟开始！如果使用my

clean.sh

，则仅需20秒以上。