buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <djspie...@gmail.com>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 21:44:00 GMT
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 <arkin@intalio.com> 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" <djspiewak@gmail.com> 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@intalio.com>
>> 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@gmail.com>
>>> 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.
>>>>
>>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message