buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 20:53:10 GMT
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.


On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <>  

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

View raw message