I always hated Maven and... Leiningen sadly uses Maven under the hood. So I've been kinda forced to use Leiningen, at least for now (because I still don't know Clojure well enough to do without it).
Wanna quickly add a private .jar file / private repo? Good luck. Oh, it's doable, sure (I did it). But it's a major pain in the arse.
People will say: "But you shouldn't use free-floating .jars". Well, guess what... I like 100% reproducible builds that do not need to connect to Internet to be build. So now to have reproducible builds we need to have not only our DVCS but also our local Maven repository. Major major pain. I much prefer to have my jars managed by myself and commit them directly in the DVCS.
People will complain that it's not the correct to do it: but meanwhile I've got an easier time reproducing builds than they do...
During all my Java years (more than ten) I always managed to dodge Maven and the rare projects I inherited that were using Maven were utter mess. People will argue that it's because of people, like me, who don't know Maven well enough, that the entire projects (and builds) became utter junk. Whatever.
Another area where Leiningen/Maven really do not shine is when you don't have Internet access (like, you know, in companies which have separate networks, including ones non-connected to the big bag Internet).
Major major pain.
And what happens if you have an Internet connection but some high-target repo gets rooted and a major Java .jar gets replaced with a version containing an exploit?
Millions of devs account instantly owned by automagic Maven updates to your project.
It hasn't happened... Yet!
But lately we've seen enough Java exploits that one can reasonably think it's not "far fetched" to imagine that such a thing could happen.
Also I hate working in an environment which can change automagically, against my will. So I'm "staging" my development by using a dev account which has no Internet access and another one which does (it's easy to do on Linux, where you can trivially use per-user firewalling rules).
I've always been amazed at how many devs cannot correctly configure a Java classpath themselves and need to be babby-sitted by a tool like Maven.
As soon as I'll understand better how Clojure and how Clojure builds do work, I'll do just like I've always done with Java projects: custom scripts building from known good .jar files.
Not some magical tool constantly "phoning home" and being a security disaster waiting to happen...
It imports some classes from Maven in order to integrate with Maven repositories, but the vast majority of Leiningen has nothing to do with Maven.
> Wanna quickly add a private .jar file / private repo? Good luck.
It's currently a bit of a pain setting up an encrypted credentials file, but once that's set up it's very straightforward to use the s3-wagon-private repository to use an S3 bucket as a repository. It's just two extra lines to your project file.
edit: Apparently Lein 2 supports unencrypted credential files now, which makes things even easier if you have full-disk encryption (or aren't worried about your credentials being read).
> And what happens if you have an Internet connection but some high-target repo gets rooted and a major Java .jar gets replaced with a version containing an exploit?
This is an issue, but I believe there's an effort to solve this in Clojars by being stricter about verifying package signatures. Already all jars uploaded to Clojars with Leiningen 2 are signed by default AFAIK.
You can also easily change the default repositories Leiningen uses when searching for packages.
> I've always been amazed at how many devs cannot correctly configure a Java classpath themselves and need to be babby-sitted by a tool like Maven.
I suspect a sizeable majority of Clojure developers can configure a classpath, but why bother if a tool can do it for you? The prospect of manually managing a dependency tree of 20, 30 or even 100 packages is just insane when Lein can do it for you.
> It imports some classes from Maven in order to integrate with Maven repositories, but the vast majority of Leiningen has nothing to do with Maven.
To be more precise, Leiningen 2 uses Sonatype Aether for dependency resolution, unlike Leiningen 1 which actually used to include Maven.
Sonatype Aether is, I believe, also the dependency resolution library used in Maven 3 (but not Maven 2) -- but it's debatable whether it is actually a part of Maven.
I was actually thinking about the Maven indexer library that Leiningen uses for searching Maven repositories, but you raise a good point about dependency resolution no longer using Maven.
I quickly add .jar files by creating the required structure under ~/.m2/repository (and potentially create a matching .pom file) and then update the project's POM to reference it and work from there. mvn will complain about a missing pom file.
It's also pretty easy to deploy a private .jar file to a Nexus repository (should you be running one). I've even seen people running httpd and copying the appropriate .jars and .poms in (for those who wanted to share with others).
> I much prefer to have my jars managed by myself and commit them directly in the DVCS.
I personally consider that to be an anti-pattern, especially if you can't discover what versions of JARs have been committed to version control by some form of metadata.
> Another area where Leiningen/Maven really do not shine is when you don't have Internet access (like, you know, in companies which have separate networks, including ones non-connected to the big bag Internet).
You can run both mvn and lein builds offline. However, you may have fun downloading/placing the appropriate project dependencies.
At one time, my 3rd-party repo almost hit 1GB (committed to SVN).
ANT script becoming more and more complicated. Running unit-test? running integration-test? SVN hooks? extra work, lots of...
Extra JARs (e.g.: Log4J 1.1 and Log4J 1.4) sometimes got included to the WAR or the deliverable output package because multiple projects refer to the same 3rd-party repo but individual project decided to use different versions of the library.
To his of its own, we decided not to move to Maven but instead opted for Ant+Ivy.
Thing is, Maven or Ivy is becoming a norm because _many_ people like me decided that it's the better way to go and we are ready to give up some of the things we had before.
Our build is 100% reproducible _and_ correct vs 100% reproducible _but_ maybe 90% correct.
One of the advantage of Maven (in Eclipse via m2clipse) is the less time it requires to setup 3rd-party JavaDoc _and_ the actual Java source code (assuming the author upload the Java source code to the M2 Repo). I can easily navigate to the source code because m2clipse will download it for me for free. Do that with ANT + Eclipse and I guarantee you that you will burn some time to set things up _AND_ it won't necessarily be cross-platform (often it won't work well across 2 different machines with the same OS anyway if someone decided to mess up with the actual .classpath).
>And what happens if you have an Internet connection but some high-target repo gets rooted and a major Java .jar gets replaced with a version containing an exploit?
Examples? Frequency? You can say the same with FreeBSD packaging, Debian and Ubuntu apt-get repo, or any similar systems.
Again, most of us are thankful that Maven (and IDE integration) exist. To bad you're not.
Wanna quickly add a private .jar file / private repo? Good luck. Oh, it's doable, sure (I did it). But it's a major pain in the arse.
People will say: "But you shouldn't use free-floating .jars". Well, guess what... I like 100% reproducible builds that do not need to connect to Internet to be build. So now to have reproducible builds we need to have not only our DVCS but also our local Maven repository. Major major pain. I much prefer to have my jars managed by myself and commit them directly in the DVCS.
People will complain that it's not the correct to do it: but meanwhile I've got an easier time reproducing builds than they do...
During all my Java years (more than ten) I always managed to dodge Maven and the rare projects I inherited that were using Maven were utter mess. People will argue that it's because of people, like me, who don't know Maven well enough, that the entire projects (and builds) became utter junk. Whatever.
Another area where Leiningen/Maven really do not shine is when you don't have Internet access (like, you know, in companies which have separate networks, including ones non-connected to the big bag Internet).
Major major pain.
And what happens if you have an Internet connection but some high-target repo gets rooted and a major Java .jar gets replaced with a version containing an exploit?
Millions of devs account instantly owned by automagic Maven updates to your project.
It hasn't happened... Yet!
But lately we've seen enough Java exploits that one can reasonably think it's not "far fetched" to imagine that such a thing could happen.
Also I hate working in an environment which can change automagically, against my will. So I'm "staging" my development by using a dev account which has no Internet access and another one which does (it's easy to do on Linux, where you can trivially use per-user firewalling rules).
I've always been amazed at how many devs cannot correctly configure a Java classpath themselves and need to be babby-sitted by a tool like Maven.
As soon as I'll understand better how Clojure and how Clojure builds do work, I'll do just like I've always done with Java projects: custom scripts building from known good .jar files.
Not some magical tool constantly "phoning home" and being a security disaster waiting to happen...