buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 21:43:14 GMT
I think the question is whether we want this in Buildr (I do) or it is
better to have a separate plugin.

Daniel seems to have prototypes for both Scala and Groovy already.


On Mon, Jan 5, 2009 at 12:53 PM, Assaf Arkin <> wrote:

> Why not start with a Scala shell?
> Nothing against Groovy, but sounds like we have a couple of people ready to
> use the Scala shell. Get that done first, and well, then worry about other
> languages.
> Assaf
> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <> wrote:
>  Probably could be, but I'm not sure how well it would integrate then.  I
>> could certainly define a Project.local_task that way, but the problem is
>> that the language-specific providers wouldn't be as nicely separated or as
>> cleanly extensible.  The nice thing about having it in Buildr itself is it
>> provides a common framework.
>> Daniel
>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <>
>> wrote:
>>  I like the idea a lot.
>>> Could this be a buildr plugin?
>>> alex
>>> On Sat, Jan 3, 2009 at 10:03 PM, 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