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.
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.
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
On Nov 15, 7:35 am, Phil Hagelberg <p...@hagelb.org> wrote:
> 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.
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.
On Nov 14, 6:35 pm, Phil Hagelberg <p...@hagelb.org> wrote:
> 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.
On Tue, Nov 15, 2011 at 9:30 AM, Daniel <doubleagen...@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.
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?
