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 22:23:34 GMT
On Mon, Jan 5, 2009 at 1:45 PM, Daniel Spiewak <> wrote:
> 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.  :-)

I think it's awesome and +1 adding it to Buildr core as a framework
that can support multiple languages/shells.

But not without documentation and specs.  We already have an issue
with undocumented/untested code that we're trying to offload (see
/addons).  A plugin is the easiest way I could think of to have other
people use it today, and get fixes/patched back into the code base.
Git branches are also good for that, but you can only use one branch
at a time, but multiple plugins.


> Daniel
> 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
>>>>>> opening up an interactive shell based on the current classpath.
>>>>>> Unfortunately, this is a somewhat tedious operation given the fact
>>>>>> 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
>>>>>> provider based on language (like most of Buildr's framework).  If
>>>>>> 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,
>>>>> there
>>>>>> is no support for JavaRebel as yet and the startup is sub-optimal
>>>>>> 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
>>>>>> 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