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