Any other thoughts on this? Without a dissenting opinion, I'm just going to filibuster my changes in regardless of potential controversy. :-)
Daniel On Sat, Jun 20, 2009 at 3:26 PM, Alex Boisvert <boisv...@intalio.com> wrote: > +1 on getting it into trunk... it's a good way to get people using it. > > My preference is still a local_task per project. > > Re: testing, have you considered capturing stdin/stdout, feeding commands > to > the interpreters and checking the results? > > alex > > > On Sat, Jun 20, 2009 at 8:41 AM, Daniel Spiewak <djspie...@gmail.com> > wrote: > > > I would like to move that my long-standing branch `interactive-shell` and > > its support branch `jruby-system` (both available from git:// > > github.com/djspiewak/buildr.git) be rebased onto trunk/ and merged into > > the > > mainline Buildr SVN. I have been dogfooding this feature for about six > > months now and have found it invaluable on many occasions. I decided > > against just "going ahead" with the merge without discussion since there > > was > > some controversy the last time we talked about this particular feature. > > Specifically, Assaf was of the opinion that the `shell` task should open > a > > shell which is global to the entire project structure, whereas I wanted > to > > make `shell` a local_task (as it is implemented in my branch). > > > > There is also a rather ugly hack that I had to add to get around a > > restriction in JRuby. Specifically, I overwrote Rake's FileUtils.sh > > method. This doesn't seem to have caused any ill effects, even though > I'm > > technically stubbing part of the API (exitstatus and pid). The only > > problem > > I'm having here is it seems to have broken shell launch (but not anything > > else) under MRI. Considering the fact that my hack only applies when > > running under JRuby, I'm not sure how this could be. If someone more > > knowledgable in the dark arts of Rake could take a look, I would greatly > > appreciate it (just run `buildr shell` in a Scala project under MRI). > > > > The main glaring omission from this contribution is specs. I can't for > the > > life of me figure out how to spec something like this, so I've settled > for > > just manually testing the heck out of it. A poor substitute, but it's > all > > I've got. If someone has any better ideas, I'm definitely open. > > > > Anyway, there has been some interest from the community in this > particular > > feature, and given its usefulness in my own development, I think that > it's > > worthy of inclusion in trunk/. Any thoughts? > > > > Daniel > > >
