buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <djspie...@gmail.com>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 22:46:46 GMT
Documentation is easy (I should be able to take care of that following the
model of the other frameworks).  As to specs, I can't even figure out how
Buildr's test setup works, so it's unlikely that I'll be able to help out
too much in that area.  :-)  If someone could point me to some documentation
on *this*, I would be much happier.

Daniel

On Mon, Jan 5, 2009 at 4:23 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Mon, Jan 5, 2009 at 1:45 PM, Daniel Spiewak <djspiewak@gmail.com>
> wrote:
> > Oh, just to add, I'm willing to put in the effort to flesh out the
> > implementation some more.  I wouldn't mind polishing the Scala provider
> > completely and perhaps adding a provider for jirb, beefing up the
> framework
> > to allow user-specified shell, etc...  Just so you know that I'm not
> dumping
> > it all on you guys.  :-)
>
> I think it's awesome and +1 adding it to Buildr core as a framework
> that can support multiple languages/shells.
>
> But not without documentation and specs.  We already have an issue
> with undocumented/untested code that we're trying to offload (see
> /addons).  A plugin is the easiest way I could think of to have other
> people use it today, and get fixes/patched back into the code base.
> Git branches are also good for that, but you can only use one branch
> at a time, but multiple plugins.
>
> Assaf
>
>
> >
> > Daniel
> >
> > On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <djspiewak@gmail.com>
> wrote:
> >
> >> The Scala shell *is* basically done.  It's missing JavaRebel support,
> which
> >> is kind-of a minor thing (incidentally, how should options like this be
> >> passed to tasks?).  It also spawns a sub-process, rather than running in
> the
> >> existing JVM.  I'm actually not sure that this is a bad idea, although
> it
> >> does impose slightly more overhead.
> >>
> >> If we want to focus on one language, then there's really no reason it
> >> couldn't be as a plugin if it's better that way.  I just thought the
> idea of
> >> a generic interactive shell framework was pretty cool.  If nothing else,
> it
> >> makes for a nicely unified syntax for the functionality across the
> different
> >> languages which Buildr supports.
> >>
> >> Another thought: coming back to the generic framework, perhaps the shell
> >> launched should be configurable?  It could default to whatever shell was
> >> associated with the compile.language, but the user could also override
> in
> >> the project definition to choose a different shell provider.  For
> example, I
> >> use jirb a lot with Java projects (scala too come to think of it).
> >>
> >> Daniel
> >>
> >>
> >> On Mon, Jan 5, 2009 at 2:53 PM, Assaf Arkin <arkin@intalio.com> wrote:
> >>
> >>> Why not start with a Scala shell?
> >>>
> >>> Nothing against Groovy, but sounds like we have a couple of people
> ready
> >>> to use the Scala shell. Get that done first, and well, then worry about
> >>> other languages.
> >>>
> >>> Assaf
> >>>
> >>>
> >>> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@gmail.com>
> >>> wrote:
> >>>
> >>>  Probably could be, but I'm not sure how well it would integrate then.
>  I
> >>>> could certainly define a Project.local_task that way, but the problem
> is
> >>>> that the language-specific providers wouldn't be as nicely separated
> or
> >>>> as
> >>>> cleanly extensible.  The nice thing about having it in Buildr itself
> is
> >>>> it
> >>>> provides a common framework.
> >>>>
> >>>> Daniel
> >>>>
> >>>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@intalio.com>
> >>>> wrote:
> >>>>
> >>>>  I like the idea a lot.
> >>>>>
> >>>>> Could this be a buildr plugin?
> >>>>>
> >>>>> alex
> >>>>>
> >>>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@gmail.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat
> is
> >>>>>> opening up an interactive shell based on the current classpath.
> >>>>>> Unfortunately, this is a somewhat tedious operation given the
fact
> that
> >>>>>> Buildr manages the classpath in its entirety.  I imagine Groovy
> users
> >>>>>> run
> >>>>>> into much the same issue on a fairly regular basis.  To solve
this
> >>>>>>
> >>>>> problem,
> >>>>>
> >>>>>> I have created a prototype implementation of
> >>>>>> Project.local_task('shell').
> >>>>>> It can be invoked as follows:
> >>>>>>
> >>>>>> # buildr shell
> >>>>>>
> >>>>>> As long as you are within a project of a supported language,
the
> >>>>>> relevant
> >>>>>> interactive shell will be launched with the -classpath already
set.
> >>>>>>  The
> >>>>>> task itself is fairly generic, being just a front which selects
a
> shell
> >>>>>> provider based on language (like most of Buildr's framework).
 If
> you
> >>>>>> aren't
> >>>>>> using a supported language (i.e. Java), the task will fail with
an
> >>>>>> appropriate message.
> >>>>>>
> >>>>>> The implementation is fairly rough.  The Scala shell works well,
but
> >>>>>>
> >>>>> there
> >>>>>
> >>>>>> is no support for JavaRebel as yet and the startup is sub-optimal
> (it
> >>>>>> launches a separate process).  The Groovy shell support is just
> >>>>>> something
> >>>>>>
> >>>>> I
> >>>>>
> >>>>>> hacked together.  It barely functions at all.  :-)
> >>>>>>
> >>>>>> This is all available in my GitHub fork:
> >>>>>> http://github.com/djspiewak/buildr/tree/master.  I would really
> love
> >>>>>> to
> >>>>>> see
> >>>>>> this feature (or something like it) make it into the Buildr
trunk/.
> >>>>>>  What
> >>>>>> does everyone else think?
> >>>>>>
> >>>>>> Daniel
> >>>>>>
> >>>>>> P.S. Oh, the fork also contains a few other goodies I've been
> working
> >>>>>> on,
> >>>>>> like a separate Specs provider and joint compilation for Scala
and
> >>>>>> Java.
> >>>>>> I'm not sure what the etiquette is on developing such features,
so I
> >>>>>> just
> >>>>>> threw them all into the master branch once I was done with their
> >>>>>> development.  The tip of each feature is tagged for slightly-easier
> >>>>>> cherry-picking, though there is some overlap in the DAG.
> >>>>>>
> >>>>>>
> >>>>>
> >>
> >
>

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