You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Reto Bachmann-Gmuer <re...@trialox.org> on 2011/01/03 22:26:44 UTC
Scala based OSGi shell (console and ssh)
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 <
reto.bachmann@trialox.org> 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 <de...@paremus.com> 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 <he...@ungoverned.org> wrote:
>>
>> > On 7/7/10 3:39, Reto Bachmann-Gmuer wrote:
>> >
>> >> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. Hall<heavy@ungoverned.org
>> >> >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
>> >>
>> >>
>> >>
>> >
>>
>
>
Re: Scala based OSGi shell (console and ssh)
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Tue, Jan 4, 2011 at 9:19 AM, Guillaume Nodet <gn...@gmail.com> 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
> <re...@trialox.org> 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 <
> > reto.bachmann@trialox.org> 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 <de...@paremus.com>
> 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 <he...@ungoverned.org> wrote:
> >>>
> >>> > On 7/7/10 3:39, Reto Bachmann-Gmuer wrote:
> >>> >
> >>> >> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. Hall<
> heavy@ungoverned.org
> >>> >> >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
>
Re: Scala based OSGi shell (console and ssh)
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<re...@trialox.org> 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 <
> reto.bachmann@trialox.org> 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 <de...@paremus.com> 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 <he...@ungoverned.org> wrote:
>>>
>>> > On 7/7/10 3:39, Reto Bachmann-Gmuer wrote:
>>> >
>>> >> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. Hall<heavy@ungoverned.org
>>> >> >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