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 Tue, 06 Jan 2009 19:42:22 GMT
Update: auto-magical JavaRebel support is now available based on the
following expression:

@rebel_home = ENV['REBEL_HOME'] or ENV['JAVA_REBEL'] or ENV['JAVAREBEL'] or

This can point to the directory or the javarebel.jar file.  In either case,
the rebel_home method will figure out what's going on and compensate
accordingly.  All of the JVM launch differences are encapsulated in the
rebel_args and rebel_props(project) methods in the Buildr::Shell::JavaRebel

With this support, it was pretty easy to enable JavaRebel launching of the
Scala shell and the Clojure shell.  This is really neat, because it means
that in both cases you get an almost-Lisp-like dynamic programming
environment with any vanilla Java, Scala or Groovy project.  JIRB also now
has support, but that was a little tricky since the JRuby launch process is
more involved.  Basically, if JRUBY_HOME is set, then that installation will
be used.  Otherwise, jruby-complete 1.1.6 will be downloaded and used
instead (this option is not preferred since it's slower).  It looks like
java/jruby.rb does some magic for when Buildr is run under JRuby; I haven't
quite figured that out yet.

Anyway, because the JIRB launch code has to basically replicate the
`bin/jruby` script, it's a lot more complicated and (thus) more prone to
bugs across different platforms.  Seems to work fine on Mac, but additional
testing is needed.


On Tue, Jan 6, 2009 at 1:34 PM, Daniel Spiewak <> wrote:

> Oh I see, allow the task to be project local, just don't define the
> local_task alias.  That would work, but again it's not as magical.
> Daniel
> On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <>wrote:
>> On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <>
>> wrote:
>> > > Yes, but I only have to do it once when I write the buildfile. All the
>> > > times I run the shell, I don't have to cd into a specific directory,
>> > > or remember the qualified task name. So if you don't need different
>> > > shells for different projects (in the same build), overall there's
>> > > much less effort setting it up this way.
>> >
>> The same could be said for the other approach.  You could easily have,
>> task 'shell' => 'myproject:shell:jirb'
>> in your project and be done with it.
>> > Oh, on a syntactic note, Lispers would know the "shell" much better as a
>> > REPL.  What's the preferred terminology?  I like shell because it's
>> short
>> > and relatively easy to understand, but maybe I'm the minority.  If
>> someone
>> > is expecting the interactive language shell to be called a "REPL", then
>> > they
>> > would probably expect `buildr shell` to be some sort of interactive
>> command
>> > interface to Buildr itself (allowing you to run tasks).  Does this seem
>> > like
>> > a potential problem or should we not fret over it?
>> I think "shell" is the more common and broader name.   And as shown above,
>> it's easy to create an alias if you insist on a specific name.
>> alex

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