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 Tue, 06 Jan 2009 22:03:41 GMT
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.


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