gogo is based on the OSGi Alliance RFC-147. Initially gogo used the org.osgi.service.command package defined by RFC-147, but as RFC-147 had not transitioned to a specification, Felix decided it was better to use an internal package to avoid possible confusion with the yet-to-be-released specification.
Karaf did not follow Felix in this respect, so still uses a package in OSGi namespace, which is not supported by a specification. I have just noticed that the OSGi Alliance have ceased work on RFC-147, so it will not become an OSGi specification. http://wiki.osgi.org/wiki/RFC_147 In terms of how to support multiple gogo-like implementations, it depends what you want to do with them. If you just want the ability to run gogo-like scripts, using CommandSession.execute(String command), you could create your own API with an execute(String command) method. Users of your API would not be exposed to the actual gogo implementation. — Derek On 14 Nov 2013, at 15:28, Daniel McGreal <[email protected]> wrote: > Hi Felix users, > > I notice that Felix's Gogo implementation uses > org.apache.felix.service.command package, whereas there seems to be a > standard (used by Knopflerfish, at least) which implements > org.osgi.service.command > I have deployment environment constrains requiring both packages for > different targets. > > Is there any advice on how to cleanly support gogo and other implementations? > I could write a wrapper for Gogo, but that seems a bit zealous. > > Thanks, Dan. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
