Documentation is easy (I should be able to take care of that following the model of the other frameworks). As to specs, I can't even figure out how Buildr's test setup works, so it's unlikely that I'll be able to help out too much in that area. :-) If someone could point me to some documentation on *this*, I would be much happier.
Daniel On Mon, Jan 5, 2009 at 4:23 PM, Assaf Arkin <[email protected]> wrote: > 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. > >>>>>> > >>>>>> > >>>>> > >> > > >
