Re: Interactive Shell Support

> 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.
>>>
>>