buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: Interactive Shell Support
Date Tue, 06 Jan 2009 01:08:22 GMT
On Mon, Jan 5, 2009 at 4:19 PM, Daniel Spiewak <> 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.


> Daniel
> On Mon, Jan 5, 2009 at 6:15 PM, Assaf Arkin <> wrote:
>> On Mon, Jan 5, 2009 at 4:02 PM, Daniel Spiewak <>
>> 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
>> >

View raw message