我正在使用autoreload-server示例，該示例非常適合使用ns-tracker更改.clj文件的重命名空間。Ennaive模板自動重新加載/檢測Pedestal服務中的更改
https://github.com/pedestal/samples/blob/master/auto-reload-server/dev/dev.clj
但是，它沒有拿起更改enlive在資源/公共目錄模板。我已經添加了我的模板路徑中DEFN手錶向量：
`([] (watch ["src" "resources" "resources/public" "public"]))`
除了這一點在使用自定義模板enlive的命名空間：
(net.cgrand.reload/auto-reload *ns*)
然而，這是行不通的。我的假設是ns-tracker僅適用於clj文件，並且我錯誤地使用了有效的重新加載功能。
是否有人使用有活力，並有這個想通了，或有任何想法嘗試？
我希望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找出哪些命名空間來重新加載。
add :resource-paths ["config", "resources"] to project.clj這樣Enlive就可以找到您的靜態HTML資源。
這些措施都不足以引起變化的資源來觸發重載，因爲ns-tracker會不注意:resource-paths。以下是詳細信息：
當你想想看，你可以看到爲什麼ns-tracker不拿起資源;他們不是Clojure命名空間。在我看來，這是連貫的設計決策，給定名稱ns-tracker。
實際上，從基座的角度來看，很明顯我們確實想在資源發生變化時重新加載。
現在，讓我再補充一點。從工具的角度來看，假設您在資源目錄中設置了一個監視。即便如此，要以細化的方式確定哪些特定的Clojure名稱空間將受到影響並不容易。一個資源可用作多個deftemplate的defsnippet。因此，一次資源更改會影響多個Clojure名稱空間。指向資源的字符串甚至可以動態構建。因此，在一般情況下，確定要重新加載的最小命名空間組可能是不可能的。所有這一切說，它應該是'容易'且足夠安全的，以便在資源發生變化時重新加載所有Clojure命名空間。
所以，總之，我自己並沒有解決這個問題，但希望我上面解釋的將幫助推動球。
我找不到現成的工作解決方案，所以我最後寫一個小環的包裝，沒有工作，看到https://github.com/kolov/enlive-reload
我也面臨這個問題。它會讓你發瘋，不是嗎？我即將鑽研代碼並看看。 –