buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 21:45:51 GMT
Oh, just to add, I'm willing to put in the effort to flesh out the
implementation some more.  I wouldn't mind polishing the Scala provider
completely and perhaps adding a provider for jirb, beefing up the framework
to allow user-specified shell, etc...  Just so you know that I'm not dumping
it all on you guys.  :-)


On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <> wrote:

> The Scala shell *is* basically done.  It's missing JavaRebel support, which
> is kind-of a minor thing (incidentally, how should options like this be
> passed to tasks?).  It also spawns a sub-process, rather than running in the
> existing JVM.  I'm actually not sure that this is a bad idea, although it
> does impose slightly more overhead.
> If we want to focus on one language, then there's really no reason it
> couldn't be as a plugin if it's better that way.  I just thought the idea of
> a generic interactive shell framework was pretty cool.  If nothing else, it
> makes for a nicely unified syntax for the functionality across the different
> languages which Buildr supports.
> Another thought: coming back to the generic framework, perhaps the shell
> launched should be configurable?  It could default to whatever shell was
> associated with the compile.language, but the user could also override in
> the project definition to choose a different shell provider.  For example, I
> use jirb a lot with Java projects (scala too come to think of it).
> Daniel
> On Mon, Jan 5, 2009 at 2: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