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" <[email protected]>
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
<[email protected]> 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 <[email protected]>
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.
