On Tue, Jan 4, 2011 at 9:19 AM, Guillaume Nodet <[email protected]> wrote:
> That looks awesome! > I'll create a karaf feature and give it a try. > great! > > 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 ? > http://svn.apache.org/viewvc/incubator/clerezza/trunk/org.apache.clerezza.parent/org.apache.clerezza.shell.felixshellcommand/ > 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.... > The :felix command forwards the commands to org.apache.felix.shell, maybe gogo-commands could directly be used as colon-prefixed commands on the scala shell. Cheers, reto > > 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 >
