On Mon, Jan 5, 2009 at 1:45 PM, Daniel Spiewak <[email protected]> wrote: > 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. :-)
I think it's awesome and +1 adding it to Buildr core as a framework that can support multiple languages/shells. But not without documentation and specs. We already have an issue with undocumented/untested code that we're trying to offload (see /addons). A plugin is the easiest way I could think of to have other people use it today, and get fixes/patched back into the code base. Git branches are also good for that, but you can only use one branch at a time, but multiple plugins. Assaf > > 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. >>>>>> >>>>>> >>>>> >> >
