
Leiningen version 2.0.0 released - llambda
https://www.github.com/technomancy/leiningen/blob/2.0.0/NEWS.md
======
jballanc
For those not familiar with Leiningen: it is a command-line tool that handles
management of project settings, build settings, dependencies, deployments,
debug console, packaging...and a whole bunch more. It is trivially extendable,
and a large number of plugins already exist. If you're familiar with Ruby,
it's the equivalent of the "rake", "gem", "rails", and "cap" commands all
rolled into one. In short, in this programmer's opinion, Leiningen is reason
enough on its own to go and learn Clojure!

~~~
codewright
I mostly hack in Python, but jballanc is not exaggerating when he says
Leiningen is reason enough to learn Clojure.

It makes cabal and sbt look _really_ bad. I would slaughter a goat for a
Leiningen equivalent in Scala or Haskell.

Go has a solid enough ecosystem already that it isn't really needed.

~~~
wheaties
I wonder just how hard it would be to take it and extend it for Scala. Just my
musing 'cause I'm learning Ruby atm and plan on learning one of Prolog,
Haskell, or Clojure next.

~~~
codewright
>I wonder just how hard it would be to take it and extend it for Scala.

That would be insanely compelling.

~~~
xeqi
<https://github.com/technomancy/lein-scalac> could be a starting point.

~~~
technomancy
The main problem here is that scalac is pretty slow, so you want to leave up
the compiler process and just trigger an incremental compile. Last I heard
this functionality was tightly coupled to SBT and not available independently.
But for simpler projects it might be OK.

~~~
BruceM
In recent months, they've made this available as "zinc" or something and it
has been integrated with Maven.

------
notdarkyet
I am still pretty new to clojure, but I really wish adding jars that are not
located in clojars or maven was a little easier (and more straightforward).

Yes, I could always take the Java project, rebuild and upload it myself. It
would be nice to just drop the jar in the libs dir and go from there.

Maybe this is already possible (but undocumented), but with all questions out
there from a simple search there is no clear way to do this that is not some
sort of a hack.

~~~
jballanc
Leiningen's package management is built upon Maven's package management. This
means that you can add artifacts directly to your local maven repo (typically
located at ~/.m2) to have them used instead. I do this frequently by checking
out a project and running `mvn install` or (if it's already a Leiningen-based
project) `lein install`.

------
DigitalJack
Congrats to technomancy and all the contributors. Leiningen is a pleasure to
work with.

~~~
burningion
Agreed, leinengen is a major part of what makes working with Clojure so
awesome. And if you haven't tried out technomancy's work with Heroku, try
spinning up an instance. It's incredibly well done.

~~~
jrheard
> And if you haven't tried out technomancy's work with Heroku, try spinning up
> an instance. It's incredibly well done.

Could you please elaborate on that? I'm not familiar with the work he's done
with Heroku.

~~~
kinleyd
From their website: "Heroku (pronounced her-OH-koo) is a cloud application
platform – a new way of building and deploying web apps. Our service lets app
developers spend 100% of their time on their application code, not managing
servers, deployment, ongoing operations, or scaling." [1]

With the arrival of technomancy at heroku, they also provide a full-stack
Clojure platform for your Clojure web applications, with a free version for
those interested in experimenting.

[1] <http://www.heroku.com/>

------
pbiggar
I remember that cake and lein were merging about a year ago, and cake's major
feature was fast startup time by reusing JVMs. Does anyone know if this was
incorporated into lein2 - I can't see it in the release notes.

~~~
JeanPierre
Fast startup time can be achieved through Drip[1], which is rather easy to
setup for Leiningen use.

[1]: <https://github.com/flatland/drip/wiki/Clojure>

~~~
pbiggar
Thanks! However, I'm not seeing any speedup. On lein 2.0.0, there doesn't seem
to be any difference between using and not using drip. (Everything I tried got
me startup times around the 28s-31s).

~~~
scottjad
Someone just fixed it, try again.

[https://github.com/flatland/drip/wiki/Clojure/_compare/87336...](https://github.com/flatland/drip/wiki/Clojure/_compare/8733641e714006f8da8ab1cb081f7a0bf6d6e23d...f953a9221f8b6f3f772b3a05903aa70746a58bad)

~~~
pbiggar
Was the fix just to the leinrc command, or should I update drip too (I'm using
0.1.8, installed via homebrew).

I tried it with the new leinrc command, and got the same result (in both cases
I verified that drip servers were being started using `ps aux | gerp drip`,
and they were).

~~~
metajack
I had this problem as well. Turns out that drip fails silently if you have
Java 6. If you get drip from the checkout (very easy and instructions are at
<https://github.com/flatland/drip>), it will work fine. Alternatively you can
upgrade to Java 7.

I've filed an issue here: <https://github.com/flatland/drip/issues/50>

------
vladev
There is giter8[1] for Scala. I wish they would join forces to make an
universal JVM project templating tool.

[1]: <https://github.com/n8han/giter8>

------
edwinnathaniel
I'm surprised that people have not appreciated Maven more seeing how there are
many praises for Leiningen.

While using Maven is like a love and hate relationship in my case, the best
tool by the next door neighbour (Clojure) is apparently a Maven like tool :)
(perhaps Leiningen is heavily inspired by Maven?).

People may dislike Maven but I found that nothing out there beats its features
and it really takes a lot of pain away in setting up (or even
maintaining/upgrading) Java projects.

I'm super glad Clojure has Leiningen. NodeJS also has a promising tool in NPM
(haven't had the chance to search around for the other related
build/deployment tools though).

~~~
TylerE

        <project xmlns="http://maven.apache.org/POM/4.0.0
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                              http://maven.apache.org/xsd/maven-4.0.0.xsd>
          <modelVersion>4.0.0</modelVersion>
          <groupId>com.mycompany.app</groupId>
          <artifactId>my-app</artifactId>
          <packaging>jar</packaging>
          <version>1.0-SNAPSHOT</version>
         <name>Maven Quick Start Archetype</name>
          <url>http://maven.apache.org</url>
          <dependencies>
            <dependency>
              <groupId>junit</groupId>
              <artifactId>junit</artifactId>
              <version>3.8.1</version>
              <scope>test</scope>
            </dependency>
          </dependencies>
        </project>
    

vs

    
    
       (defproject leiningen.org "1.0.0"
          :description "Generate static HTML for http://leiningen.org
          :dependencies [[enlive "1.0.1"]]
          :main leiningen.web)

~~~
edwinnathaniel
Granted many many many people use Eclipse/NetBeans/IntelliJ to come up with
the XML.

If this is a concern, you can always use the mvn command-line passing
arguments and archetype to generate the first skeleton XML.

I'm not nitpicking when it comes to XML vs LISP for configuration syntax.

Features is what I'm looking for so I would have to pass arguing minor things
like this.

Thanks for the example though.

------
martinced
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...

~~~
weavejester
> Leiningen sadly uses Maven under the hood.

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.

~~~
nathell
> 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.

~~~
weavejester
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.

