Leiningen and Cake

Showing 1-6 of 6 messages
Leiningen and Cake Phil Hagelberg 11/14/11 4:35 PM
Hello folks.

You may have heard some rumours and/or tweetage about Cake and
Leiningen. During the Conj I met with Justin Balthrop and some of the
other Cake developers. They were interested in joining forces to
develop a single unified build tool for Clojure. We talked it through
and I think Leiningen could definitely benefit on the one hand from
having a few of Cake's features ported over and on the other hand from
gaining a bunch of new developers. This will mean Cake may see another
few releases but will have its development efforts directed to
Leiningen.[1]

In particular I'm thinking of two or three things that make sense to
take from Cake for Leiningen 2.0. Firstly there's the use of
in-process classloaders for project execution. I've wanted this for a
while, and they've got a nice well-tested implementation they're
offering to have ported right over. This should speed things up and
offer fairly significant memory savings. The other definite win would
be taking the SCP implementation for Clojars uploads. There is a
lein-clojars plugin, but it has some issues with keys that have
prevented it from being considered for inclusion.

Another thing we may take is the notion of "profiles" or environments
in which tasks execute. Right now Leiningen has a notion of dev time
vs production, which is just a single bit that determines whether
dev-dependencies, tests, and test resources are on the classpath. Cake
(and Maven IIUC) expand on this and allow various config options to be
grouped and activated on a per-profile basis. I'll start a separate
thread discussing this since there's still a fair bit more I'd like to
understand about how people are using this in Cake and how simply it
could be implemented.

We're still thinking through whether it makes sense for Leiningen to
offer persistent/daemonized JVMs to reduce execution time; it may be
simpler to delegate this to Jark[2] instead since it could be
considered fairly orthogonal. If you use Cake and Leiningen and have
some other features you would miss, please mention them.

So I'm excited to welcome them to the team.

Happy Hacking.

-Phil

[1] - https://groups.google.com/group/clojure-cake/browse_thread/thread/186ec36c2426996e
[2] - http://icylisper.in/jark

Re: Leiningen and Cake Stefan Kamphausen 11/15/11 2:31 AM
Hi,

this definitely sounds like a good move.

For me the persistent JVM was the main reason to work with cake for a while.  It really helped me during development of tests and when I used marginalia.

Just my 2ct.


Kind regards,
Stefan
Re: Leiningen and Cake Jeff 11/15/11 7:39 AM
Great news!  I've been hoping this merger would happen some day.  When
I shifted over to cake a while back there were two main reasons:

* cleaner and more reliable handling of native library dependencies,
built-in
* ability to define makefile like dependency tasks
 - really handy for scripting server deployment, logfile processing
tasks, etc. (like with rake)

The persistant JVM is very handy for running these kinds of sub-tasks,
so in my mind they go together.  I also found myself using "cake ps"
and "cake killall" fairly often during development, especially when
running various web service daemons in the background.

This will be a great move for the Clojure community.  I know at least
for Overtone users it will be nice to unify on a single build tool.

Cheers,
Jeff
> [1] -https://groups.google.com/group/clojure-cake/browse_thread/thread/186...
> [2] -http://icylisper.in/jark
Re: Leiningen and Cake Daniel 11/15/11 9:30 AM
The persistent jvm (and tasks that go with it), nailgun task, contexts
(https://github.com/flatland/cake/wiki/Contexts), task definition in a
single file....

Also, ease of installation.  'gem cake' is infinitely simpler than any
install process I've ran across for leiningen (albeit a little off-
putting).  We should at least have leiningen in an apt-get repository,
or an ebuild submitted, or something of that sort.

Some of those may not (or no longer be) differences.  The persistent
jvm pulled me away from leiningen too early, before I could learn much
about it.
Re: Leiningen and Cake Phil Hagelberg 11/15/11 10:03 AM
On Tue, Nov 15, 2011 at 9:30 AM, Daniel <double...@gmail.com> wrote:
> Also, ease of installation.  'gem cake' is infinitely simpler than any
> install process I've ran across for leiningen (albeit a little off-
> putting).  We should at least have leiningen in an apt-get repository,
> or an ebuild submitted, or something of that sort.

Leiningen 1.6.1.1 is actually in Debian and Ubuntu, with 1.6.2 just
waiting to be sponsored for upload to unstable. It's also in homebrew
and (I believe) macports. Getting it into Gentoo and rpm-based package
managers would be great if anyone has expertise there. I have created
a bin/lein-pkg script especially for packagers that has things like
self-install and upgrade stripped out since these are only relevant
for the manual install.

-Phil

Re: Leiningen and Cake Phil Hagelberg 11/15/11 10:27 AM
On Tue, Nov 15, 2011 at 7:39 AM, Jeff <ros...@gmail.com> wrote:
> Great news!  I've been hoping this merger would happen some day.  When
> I shifted over to cake a while back there were two main reasons:
>
> * cleaner and more reliable handling of native library dependencies, built-in

This was actually added in version 1.6.0. I have superficially tested
it on most of the libraries I could find that used native
dependencies, but it would be helpful to get more eyes on that feature
in particular. Also the _creation_ of jars that contain native deps
leaves much to be desired from what I've heard, though this is
probably plugin material.

> The persistant JVM is very handy for running these kinds of sub-tasks,
> so in my mind they go together.  I also found myself using "cake ps"
> and "cake killall" fairly often during development, especially when
> running various web service daemons in the background.

I understand that this is very handy, but it seems to me like it could
be handled orthogonally to Leiningen itself. Jark is making an effort
to handle persistent JVMs for various purposes including Leiningen
tasks, and it's my initial inclination to delegate to it instead. If
you're a heavy user of the persistent JVM, I'd encourage you to at
least try out Jark and give them feedback.

I would rather avoid hoisting the conceptual complexity of process
management onto the user by default. It's not off the table to add it
as an optional feature of Leiningen, but we should think through the
options. If the main motivation is just to avoid an extra step of
installing Jark, maybe it would be better to help with packaging up
Jark to make it easier to install?

-Phil