Posed the question to the community at large (all five of my readers): http://www.codecommit.com/blog/java/hacking-buildr-interactive-shell-support
With any luck, we'll get some feedback indicating general feeling on this subject. Daniel On Tue, Jan 6, 2009 at 4:03 PM, Daniel Spiewak <[email protected]> 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 <[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 >> > >
