On Mon, Jan 5, 2009 at 4:19 PM, Daniel Spiewak <[email protected]> wrote: > 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.
I think the only difference is that I would have one CLASSPATH that grows (and sometimes shrinks) over time, rather than jumping between projects. A matter of style. I obviously prefer my style, but my advise right now would be to pick one option, code it, and start using it, and see over time if it feels restricting/annoying. Also, open a JIRA issue for this enhancement so we can track it. Assaf > > 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 >> > >> >
