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