Oh, just to add, I'm willing to put in the effort to flesh out the implementation some more. I wouldn't mind polishing the Scala provider completely and perhaps adding a provider for jirb, beefing up the framework to allow user-specified shell, etc... Just so you know that I'm not dumping it all on you guys. :-)
Daniel On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <[email protected]> wrote: > The Scala shell *is* basically done. It's missing JavaRebel support, which > is kind-of a minor thing (incidentally, how should options like this be > passed to tasks?). It also spawns a sub-process, rather than running in the > existing JVM. I'm actually not sure that this is a bad idea, although it > does impose slightly more overhead. > > If we want to focus on one language, then there's really no reason it > couldn't be as a plugin if it's better that way. I just thought the idea of > a generic interactive shell framework was pretty cool. If nothing else, it > makes for a nicely unified syntax for the functionality across the different > languages which Buildr supports. > > Another thought: coming back to the generic framework, perhaps the shell > launched should be configurable? It could default to whatever shell was > associated with the compile.language, but the user could also override in > the project definition to choose a different shell provider. For example, I > use jirb a lot with Java projects (scala too come to think of it). > > Daniel > > > On Mon, Jan 5, 2009 at 2: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. >>>>> >>>>> >>>> >
