This is not directly answering the OP's question, but skuro mentioned something in his last paragraph which can be quite useful, i.e. to make resources available on the classpath during development, but not include them in the release jar/uberjar.
The reason of that is then you could place the resources separately outside of the jar – for example placing configuration files under /etc
– and then link to them at runtime by listing such resource folders on the classpath.
Definitions in project.clj
- remove the top-level
:resource-paths
from your project.clj;
- add the following lines in the project.clj at the top level:
:profiles {:dev {:resource-paths ["src/main/resources"]}}
This way the resources will be available on the classpath during development (compile, test, repl), but will not be included in the release jars.
As an altenative, you might want to bundle some of the resources with the release jar, like application icons and graphics, but not others, like configuration files. In that case you could split the resources folder into subdirectories and declare the ones you want to get included at the top level, while the rest under the dev
profile:
:resource-paths ["src/main/resources/icons"
"src/main/resources/images"]
:profiles {:dev {:resource-paths ["src/main/resources/config"]}}
Referencing resources in code
Using the above method you could reference resources both during development and production uniformly by looking them on the classpath (as shown by Kevin and Valerii), and not directly on the filesystem:
(require '[clojure.java.io :as jio])
(jio/file (jio/resource "relative/path/to/resource.xml"))
Runtime classpath
During development Leiningen would include both the top level and the dev
profile resources on the classpath. For the released runtime you will have to configure the classpath for the JRE yourself:
java -cp "/etc/myapp:/usr/local/lib/myapp.jar" myapp.core $*
Also, alternatively you can in fact leave all the resources included in the jar. That way the included resources would be used as defaults. If you set up the classpath so that the .jar file comes after the configuration folder (/etc/myapp
in the example), then the resource files with the same relative resource path under the configuration folder will take precedence over the ones included in the jar.