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 <[email protected]> wrote: > On Tue, Jan 6, 2009 at 12:24 PM, Assaf Arkin <[email protected]> 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 >
