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<he...@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
>>
>>
>>
>
