That looks awesome!
I'll create a karaf feature and give it a try.

Btw, I haven't seen the source code location for the
mvn:org.apache.clerezza/org.apache.clerezza.shell.felixshellcommand/0.1-incubating-SNAPSHOT
bundle, could you point me to it please ?
I wanted to see if you do as in gogo, i.e. registering any function
registered in osgi with the correct properties as a command (that
would enable access to all gogo-based commands directly), or if you
were just wrapping the old felix commands somehow....

On Mon, Jan 3, 2011 at 22:26, Reto Bachmann-Gmuer
<[email protected]> wrote:
> Ok, it took me some time to actually implement the Scala based OSGi console.
> For an introduction see:
> http://incubator.apache.org/clerezza/getting-started/shell/
>
> To try it out you may either download a recent launcher for clerezza from
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/clerezza/org.apache.clerezza.platform.launcher.tdb/0.5-incubating-SNAPSHOT/
>
> alternatively you may install the shell manually in your container, by
> installing and starting the following bundles (mvn uris to be resolved from
> the repo above)
>
> mvn:org.apache.clerezza.scala/scala-compiler-osgi/0.1-incubating-SNAPSHOT
> mvn:org.apache.clerezza.scala/scala-library-osgi/0.1-incubating-SNAPSHOT
> mvn:org.apache.clerezza.scala/script-engine/0.1-incubating-SNAPSHOT
> mvn:org.apache.clerezza/org.apache.clerezza.shell/0.1-incubating-SNAPSHOT
> mvn:org.apache.clerezza/org.apache.clerezza.shell.felixshellcommand/0.1-incubating-SNAPSHOT
> (optional, allows to execute classic felix shell commands)
>
> to allow access via ssh (default port 8022) the following bundles are
> required additionally:
>
> mvn:org.apache.clerezza/org.apache.clerezza.sshshell/0.1-incubating-SNAPSHOT
> mvn:org.apache.mina/mina-core/2.0.2
> mvn:org.apache.sshd/sshd-core/0.5.0
> mvn:org.apache.sshd/sshd-pam/0.5.0
>
> Cheers,
> Reto
>
>
> PS: I put together the lists of bundle uris above from the scala shell using
> the following commands on the scala based shell:
>
> zz>for (b <- bundleContext.getBundles; if
> b.getLocation.contains("clerezza.scala") ||
> b.getLocation.contains("clerezza.shell")) out println b.getLocation
> zz>for (b <- bundleContext.getBundles; if b.getLocation.contains("ssh") ||
> b.getLocation.contains("mina")) out println b.getLocation
>
>
>
>
>
> On Mon, Jul 12, 2010 at 1:38 PM, Reto Bachmann-Gmuer <
> [email protected]> wrote:
>
>> I think once we have the scala console working registering a gogo command
>> to access it should be quite straight forward. Still I think the independent
>> scala console should best be implemented first.
>>
>> Cheers,
>> reto
>>
>>
>> On Fri, Jul 9, 2010 at 5:56 PM, Derek Baum <[email protected]> wrote:
>>
>>> I've recently been experimenting with adding groovy support for gogo, and
>>> I
>>> assume that scala would be similar.
>>>
>>> My use-case is that although gogo is scriptable, it was never intended to
>>> be
>>> used instead of groovy or scala.
>>>
>>> I therefore wanted the ability to run a full blown groovy script from
>>> gogo,
>>> giving the script access to my gogo session variables and an OSGi context.
>>> Here's a brief look of what it can do so far:
>>>
>>> [Note: I'm using posh here, which is part of our commercial Nimble
>>> product,
>>> but this could easily be ported to gogo]
>>>
>>> % cat hello.groovy
>>> #!/usr/bin/env posh -c groovy
>>>
>>> println "hello, groovy!"
>>>
>>> // access bundle context
>>> println context.bundle
>>>
>>> // run gogo command
>>> def b0 = session.execute("bundle 0")
>>> println "b0=" + b0
>>>
>>> // concatenate arguments from gogo
>>> def result = ""
>>>
>>> for (arg in this.args) {
>>>  println "Argument:" + arg.class + ": " + arg;
>>>  result += arg
>>> }
>>>
>>> return result
>>> %
>>>
>>> # now run hello.groovy script from posh/gogo
>>> # note: that arguments and return value are handled correctly
>>>
>>> % groovy hello.groovy $HOME $SHLVL
>>> hello, groovy!
>>> com.paremus.posh.runtime_1.0.21.SNAPSHOT [1]
>>> b0=org.eclipse.osgi_3.6.0.v20100517 [0]
>>> Argument:class java.net.URI: file:/Users/derek/
>>> Argument:class java.lang.Integer: 1
>>> %
>>> % echo $_
>>> file:/Users/derek/1
>>> %
>>>
>>>
>>>
>>> # now run groovy interactively from posh/gogo
>>> # this is less advanced, as there is no command-line editting or
>>> completion.
>>> # rather than posh/gogo try to provide this, it should be provided by the
>>> scripting environment
>>> # so that gogo/scala shell handles completion/editting in exactly the same
>>> way as the non-OSGi scala shell.
>>>
>>> % groovy
>>> groovy$ println context.bundle(0)
>>> groovy: groovy.lang.MissingMethodException: No signature of method:
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.bundle() is
>>> applicable for argument types: (java.lang.Integer) values: [0]
>>> Possible solutions: getBundle(), getBundle(long), getBundles(),
>>> findAll(groovy.lang.Closure), find(groovy.lang.Closure),
>>> use([Ljava.lang.Object;)
>>> groovy$
>>> groovy$ println context.getBundle(0)
>>> org.eclipse.osgi_3.6.0.v20100517 [0]
>>> groovy$ %
>>>
>>>
>>> Does this have any synergies with what you're want to do, assuming we can
>>> create similar functionality using scala?
>>>
>>> Regards,
>>>
>>> Derek
>>>
>>>
>>>
>>> On 7 July 2010 15:39, Richard S. Hall <[email protected]> wrote:
>>>
>>> > On 7/7/10 3:39, Reto Bachmann-Gmuer wrote:
>>> >
>>> >> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. Hall<[email protected]
>>> >> >wrote:
>>> >>
>>> >> I'm not too familiar with Scala, so pardon my ignorance.
>>> >>
>>> >>
>>> >>> So is the proposal to have some sort of Scala-based console/shell?
>>> Does
>>> >>> this mean you can do Scala-based scripting and syntax? Is this
>>> something
>>> >>> that could simply be another shell front end for the Gogo runtime or
>>> is
>>> >>> it
>>> >>> somehow completely different?
>>> >>>
>>> >>>
>>> >>>
>>> >> I must  admit I'm not familiar with OSGi RFC-147 so I'm not sure if it
>>> >> could
>>> >> be implemented on it.
>>> >>
>>> >> To be as attractive for people currently not using OSGi it should feel
>>> as
>>> >> much as possible like the scala console, this includes:
>>> >> - autocompletion with tab
>>> >> - multi-line expressions (afte an incomplete expression such as one
>>> >> opening,
>>> >> but not closing a bracket a continuation-prompt appears)
>>> >>
>>> >> Once we have this we can add a DSL to more easily do OSGi related tasks
>>> >> (listing services and bundles, accessing services, etc. )
>>> >>
>>> >>
>>> >
>>> > Well, I still can't say I totally understand what is being proposed, but
>>> > I'm not against having people work on it at Felix if other people think
>>> its
>>> > worthwhile. If it does ultimately blossom into a full-blown shell for
>>> OSGi,
>>> > then there will certainly be some overlap with Gogo, but we can always
>>> look
>>> > for ways to bridge the two...
>>> >
>>> > -> richard
>>> >
>>> >  Reto
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to