One disadvantage I have found to the project local technique is the fact that I can't figure out how to make tasks like 'shell:jirb' project local. This means that if you want to launch a custom shell, you have to fully-qualify the task:
buildr collection:shell:jirb In other news, I have now added this mythical JIRB shell provider, as well as a provider for the Clojure shell (id :clj). Both of these depend on their respective *_HOME environment variables. The Groovy shell provider is also now up to snuff, though I can't tell if the annoying associated app launch is on purpose or not. For everything except the Scala shell provider, we probably should dynamically install the artifacts into the local repo, mirroring the compile tasks. I'm lazy though, and for the moment I've left this alone. The one exception is the JLine dependency for the Clojure shell, which I grab using Buildr.artifact. Incidentally, the Clojure shell might be something worth dropping just for continuity, since nothing else in Buildr actually supports that language. However, I figured there was no harm in implementing a quick prototype so we can see how things will work. This is all still in flux anyway. Daniel On Mon, Jan 5, 2009 at 7:35 PM, Daniel Spiewak <[email protected]> wrote: > > 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. > > > Coded! :-) http://github.com/djspiewak/buildr Branch: interactive-shell > > It's worth noting that I rarely use sub-projects, so in practice my style > and yours are likely indistinguishable. I'm curious as to the opinion of > the community at large. > > Out of curiousity, in your style, you do you envision the shell task > determining the correct compile task? This task must be a pre-requisite for > `shell`. Also, the task needs to be able to locate CLASSPATH information > from somewhere. If the task isn't project-local, where does it come from? > > Also, open a JIRA issue for this enhancement so we can track it. > > > https://issues.apache.org/jira/browse/BUILDR-234 > > Daniel >
