buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Interactive Shell Support
Date Sun, 04 Jan 2009 17:06:27 GMT
I like the idea a lot.

Could this be a buildr plugin?

alex

On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@gmail.com> 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:
> http://github.com/djspiewak/buildr/tree/master.  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.
>

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