Yeah, this is the sort of thing I was thinking about too, although in
fewer details... ;-)
Not sure if it is exactly what is desired, but it creates a nice story
if it proves workable...
-> richard
On 7/9/10 11:56, Derek Baum 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
