Re: Interactive Shell Support

> 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" <djspiewak@...> 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 <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 <djspiewak@...>
>>> 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.
>>>>
>>>>
>>>