On Tue, Nov 15, 2011 at 7:39 AM, Jeff <ros...
> 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?