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

Daniel

On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <djspiewak@gmail.com> 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 <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