Ah, we have very different needs for this feature! :-) To me, the sort of shell you describe would be nearly useless on complex projects. I would definitely want to get a different CLASSPATH if I'm in a sub-project. The main reason I want the shell is to test perform Lisp-style dynamic development on internal classes which I'm still working on. The external interface to the project might be nice to hit, but that's a separate issue for me. Most of the time, my client-facing testing would be in the form of unit tests requiring more setup than a shell can nicely accommodate.
Daniel On Mon, Jan 5, 2009 at 6:15 PM, Assaf Arkin <[email protected]> wrote: > On Mon, Jan 5, 2009 at 4:02 PM, Daniel Spiewak <[email protected]> > wrote: > >> I think for most builds you only need one shell, so a per-buildfile > >> shell is easier to work with, configure, etc. > > > > > > The whole point to the shell framework is to launch a shell easily with > the > > CLASSPATH already configured. If we don't do that on a per-project > basis, > > it's useless. > > Say I'm working on a Web application, there's a lot of > components/modules involved, but I only really need to shell into one > place. It's a shell that puts me in much the same place I'd be as the > server or a client (e.g I can use data access objects, or make > requests). Most often than not, and I am thinking of very complicated > applications, I don't need more than one shell. > > I do expect the shell to have the CLASSPATH already configured. And I > expect to do minimal work in the buildfile to get that CLASSPATH > configured. And I would expect, whichever directory I'm in, that > buildr shell drops me in the right shell with that one CLASSPATH. > > Assaf > > >> I know scenarios where I would like to (or have and so use) multiple > >> shells, but those are task-based not project-based. For example, when > >> working with Rails, I use the server console, database console > >> (embedded sqlite), and bash/irb for the client. > >> > >> So it would be nice if I could easy define new shells from the > buildfile, > >> say: > >> > >> ShellTask.define_task('client').with( lots of dependencies ) > > > > > > That would be pretty cool, though I'm not quite sure how it would work. > > This might also be useful if you want to start a shell which always > > pre-inits itself with some code (a bunch of imports for example, or a > long > > setup task). > > > > Daniel > > >
