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 >> >> >> >> >> >> >> > >> > >
