+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 <[email protected]> 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 >
