我正在使用autoreload-server示例，该示例适用于使用ns-tracker重新加载.clj文件更改时的命名空间。
https://github.com/pedestal/samples/blob/master/auto-reload-server/dev/dev.clj
但是，它没有对资源/公共目录中的活动模板进行更改。我在defn watch中添加了我的模板路径：
`([] (watch ["src" "resources" "resources/public" "public"]))`
在使用enlive deftemplate的命名空间中也是如此：
(net.cgrand.reload/auto-reload *ns*)
然而，这不起作用。我的假设是ns-tracker仅适用于clj文件，而且我使用的是enlive重载功能。
是否有人使用了enlive并想出这个想法，或者有什么想法尝试？
答案 0 :(得分：0)
我希望Enlive Issue #6: Auto-reloading of templates在2013年12月初的版本1.1.5中由this commit解决。但是，在我的测试中，我无法确认这是一个修复。我可能做错了。
注意：我认为，您引用的示例可以追溯到pre-0.2.0 tooling changes for Pedestal。我可能错了，但我认为你最好不要使用当前的文档，而不是那个示例文件。
Pedestal's 'hello world' service app的主要建议（可能会改变）是：
使用ns-tracker确定要重新加载的命名空间。
将:resource-paths ["config", "resources"]添加到project.clj，以便Enlive可以找到您的静态HTML资源。
这些步骤不足以导致更改资源以触发重新加载，因为ns-tracker不会关注:resource-paths。以下是详细信息：
当你考虑它时，你可以看到为什么ns-tracker没有获取资源;它们不是Clojure命名空间。在我看来，这是一个连贯的设计决策，名称为ns-tracker。
但实际上，很明显，从Pedestal的角度来看，当资源发生变化时，我们确实想重新加载。
现在，让我补充一点。从工具的角度来看，假设您在资源目录中设置了监视。即便如此，以粒度方式识别哪些特定的Clojure名称空间将受到影响并不容易。一个资源可以被多个deftemplate用作defsnippet。因此，一个资源更改可能会影响多个Clojure命名空间。指向资源的字符串甚至可以动态构造。因此，在一般情况下，找出要重新加载的确切最小命名空间集可能是不可能的。
所有这些都说，只要资源发生变化，就应该“轻松”，安全地重新加载所有Clojure名称空间。
所以，总而言之，我自己并没有解决这个问题，但希望我上面所解释的将有助于推动这一进程。
答案 1 :(得分：0)
我无法找到现成的工作解决方案，所以我最终编写了一个小环形包装来完成这项工作，请参阅https://github.com/kolov/enlive-reload