buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <>
Subject Re: Interactive Shell Support
Date Mon, 12 Jan 2009 08:00:02 GMT
Posed the question to the community at large (all five of my readers):

With any luck, we'll get some feedback indicating general feeling on this


On Tue, Jan 6, 2009 at 4:03 PM, Daniel Spiewak <> wrote:

> Using test.dependencies is an interesting idea.  The problem then is we'll
> end up pulling in things like junit:jar, which isn't even remotely necessary
> for regular shell stuff.  Also, that raises the question: should we include
> _(:target, :test, :classes) as well?  If we do, then we have to depend on
> 'test:compile', which means that a straight shell launch will take twice as
> long on a clean project.
> I'm not sure that making tasks like `jirb` top-level is a good idea.  For
> one thing, it might lead to name collision down the road (e.g. "scala").
> Also, it doesn't "read" (at least to my eyes) like launching a shell.
> "buildr scala" almost looks like you're building a new version of Scala
> itself.  I think that "buildr shell:scala" or even "buildr shell[scala]" is
> more clear what's actually going on.
> I agree that we need to decide what the common case is and optimize that.
> I'll try to solicit some wider community input on the feature; we'll see
> what we get.
> Daniel
> On Tue, Jan 6, 2009 at 2:44 PM, Alex Boisvert <>wrote:
>> On Tue, Jan 6, 2009 at 12:24 PM, Assaf Arkin <> wrote:
>> > The question is, what is the common case. If we could decide on that,
>> > we should definitely optimize for the common case.
>> Reframing this way, I would say that my common case would be telling
>> Buildr
>> exactly which interpreter I want to run with a given project so it knows
>> which dependencies I want to preload, e.g.,
>> buildr jirb[myproject]
>> or
>> buildr scala[myproject:subproject]
>> And I would expect Buildr use the test dependencies of the project since
>> those are usually more complete than the compile dependencies (that
>> usually
>> include only APIs and no implementation).
>> alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message