buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <>
Subject Interactive Shell Support
Date Sun, 04 Jan 2009 06:03:04 GMT
I use Buildr a lot for Scala, and one pattern I consistently repeat is
opening up an interactive shell based on the current classpath.
Unfortunately, this is a somewhat tedious operation given the fact that
Buildr manages the classpath in its entirety.  I imagine Groovy users run
into much the same issue on a fairly regular basis.  To solve this problem,
I have created a prototype implementation of Project.local_task('shell').
It can be invoked as follows:

# buildr shell

As long as you are within a project of a supported language, the relevant
interactive shell will be launched with the -classpath already set.  The
task itself is fairly generic, being just a front which selects a shell
provider based on language (like most of Buildr's framework).  If you aren't
using a supported language (i.e. Java), the task will fail with an
appropriate message.

The implementation is fairly rough.  The Scala shell works well, but there
is no support for JavaRebel as yet and the startup is sub-optimal (it
launches a separate process).  The Groovy shell support is just something I
hacked together.  It barely functions at all.  :-)

This is all available in my GitHub fork:  I would really love to see
this feature (or something like it) make it into the Buildr trunk/.  What
does everyone else think?


P.S. Oh, the fork also contains a few other goodies I've been working on,
like a separate Specs provider and joint compilation for Scala and Java.
I'm not sure what the etiquette is on developing such features, so I just
threw them all into the master branch once I was done with their
development.  The tip of each feature is tagged for slightly-easier
cherry-picking, though there is some overlap in the DAG.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message