You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Daniel Spiewak (JIRA)" <ji...@apache.org> on 2009/06/09 23:52:07 UTC

[jira] Assigned: (BUILDR-234) Generic Interactive Shell Framework

     [ https://issues.apache.org/jira/browse/BUILDR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Spiewak reassigned BUILDR-234:
-------------------------------------

    Assignee: Daniel Spiewak

> Generic Interactive Shell Framework
> -----------------------------------
>
>                 Key: BUILDR-234
>                 URL: https://issues.apache.org/jira/browse/BUILDR-234
>             Project: Buildr
>          Issue Type: New Feature
>          Components: Core features
>            Reporter: Daniel Spiewak
>            Assignee: Daniel Spiewak
>
> It is often desirable to launch an interactive shell provided by some underlying language.  For example, when using Buildr for Scala projects, I often use the `scala` interactive shell.  On Groovy projects, it is extremely common to use `groovysh`.  This can get tedious however because the CLASSPATH is entirely managed by Buildr.  Launching these shells by hand requires either an extremely verbose invocation or an extra wrapper script which easily becomes outdated.
> A solution to this would be to add a core framework to Buildr which would allow multiple shell providers.  The default would be that which corresponds to the project's language (if any).  Thus, in a Scala project:
> # buildr shell
> ...will launch `scala`; in a Groovy project, `groovysh` would be launched; and in a Java project the task would fail.  It should also be possible to specify which shell is desired:
> # buildr shell:jirb
> Alternatively:
> # buildr shell[jirb]
> These shells should be launched with the CLASSPATH already set including all build artifacts as well as compiled classes.  Thus, :shell => :compile.  It is the opinion of this developer that the shell CLASSPATH should reflect that of the currently active project / sub-project (depending on CWD).  An alternative design would have the CLASSPATH based solely on the outermost project regardless of CWD.  See http://www.nabble.com/Interactive-Shell-Support-to21273331.html
> A preliminary implementation of this feature is available in the `interactive-shell` branch of this Git fork:  http://github.com/djspiewak/buildr

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.