buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <>
Subject Re: Interactive Shell Support
Date Sun, 04 Jan 2009 08:21:12 GMT
Correction.  I've done some playing with the repo and now the interactive
shell is separated into its own branch: interactive-shell.  This should make
it easier to evaluate in isolation from the separate-scala-specs and
scala-joint-compilation enhancements.  The master branch still contains all
three (since that's the one I'm using locally).


On Sun, Jan 4, 2009 at 12:03 AM, Daniel Spiewak <> wrote:

> 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?
> Daniel
> 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