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 04:14:38 GMT
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

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.


On Mon, Jan 5, 2009 at 7:35 PM, Daniel Spiewak <> 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!  :-)  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.
> Daniel

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