I think the question is whether we want this in Buildr (I do) or it is better to have a separate plugin.
Daniel seems to have prototypes for both Scala and Groovy already. alex On Mon, Jan 5, 2009 at 12:53 PM, Assaf Arkin <[email protected]> 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" <[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. >>>> >>>> >>>
