leiningen - how to add dependencies for local jars?

Just use :resource-paths in your project.clj file. I use it, e.g. to connect to Siebel servers. Just created a resources directory in my project directory and copied the jar files in there. But of course you could use a more generic directory:

(defproject test-project "0.1.0-SNAPSHOT":description "Blah blah blah"...:resource-paths ["resources/Siebel.jar" "resources/SiebelJI_enu.jar"])

Then from the lein repl I can create Siebel Data Bean instances, e.g.

(def sbl (com.siebel.data.SiebelDataBean.))(.login sbl "siebelServer" "user" "password")...

If you have a newer Java version you can of course use wildcards in your path specification like this for a more general directory:

:resource-paths ["/tmp/SiebelJars/*"]

1. Create a directory in the project:

   mkdir maven_repository

2. Add local jars to this repository:

   For example, this command adds the jaad-0.8.3.jar file to the mavenrepository:

   mvn deploy:deploy-file -Dfile=jaad-0.8.3.jar -DartifactId=jaad -Dversion=0.8.3 -DgroupId=jaad -Dpackaging=jar -Durl=file:maven_repository

3. Add the following to project.clj

   :repositories {"local" "file:maven_repository"}

4. Now a regular lein deps should work:

   $ lein depsDownloading: jaad/jaad/0.8.3/jaad-0.8.3.pom from localTransferring 0K from local[WARNING] *** CHECKSUM FAILED - Error retrieving checksum file for jaad/jaad/0.8.3/jaad-0.8.3.pom - IGNORING

The warning can be ignored, since the jar will be checked into the project and not downloaded from the internet.

Original source: Using local JAR's with Leiningen (changed since copying)

You could put your private jars in lib/ and they'd be on the classpath for the purposes of lein swank and the like; this does seem to defeat the point of using a dependency management tool, though if you don't actually want those dependencies managed, you could treat Leiningen as an "open source dependencies management tool" and maybe be careful with lein clean.

As the situation becomes more complex -- there's a larger number of private jars involved, they evolve and you need to take some versioning info on them into account -- Arthur's idea of creating a private Maven repo may be more appropriate.

(The HR signifies Leiningen-specific part cut-off point... Continue below for information on the general build / dependency management tooling story in Clojure land, including some links which I think could come in very handy in your situation.)

Also, as of yet, there is no universal agreement on the question of which is the best build tool for Clojure, and Leiningen, while gaining in mindshare, is also constantly gaining in the areas features and polish -- meaning, in particular, that it's not yet complete. Here's a quote from Stuart Halloway, the author of Pragmatic Bookshelf's "Programming Clojure": "My 2c: Leiningen is an important step, but there is still plenty to do." For the full posting and a very interesting discussion re: build tools and the like in Clojure space, see the Leiningen, Clojure and libraries: what am I missing? thread on the Clojure Google group. Many participants specifically mention the need to have local dependencies not contained in any repositories, local or otherwise, and elaborate on the solutions they've come up with for such scenarios. Perhaps you could see if there's anything over there which can solve your problem now / might solve it in the future, when feature sets mature?

Anyway, it is possible that Leiningen may not in fact have a good story ready yet for some complex scenarios. If you feel this may be true of your case (and I mean after you consider the private repo idea), here's some links to maven-based alternatives taken from the above mentioned thread: polyglot maven, clojure-maven-plugin; this blog posting aims to be useful to people trying to use maven with Clojure. As I recall, Meikel Brandmeyer (also on SO under his online handle of kotarak) uses Gradle (a Groovy build system) with a plugin to accomodate Clojure called Clojuresque; I never tried it myself, as don't know the first thing about Groovy, but he claims to run a very nice building act with it and I believe it's got nothing to do with maven -- something which is a plus in and of itself for some of us. :-)