You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Daniel McGreal <da...@redbite.com> on 2013/11/14 16:28:21 UTC
Gogo and CommandProcessor, etc interfaces
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo and CommandProcessor, etc interfaces
Posted by Daniel McGreal <da...@redbite.com>.
Hi Derek, thanks for the information. It's now clear.
On 14 Nov 2013, at 16:11, Derek Baum wrote:
> 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.
Re: Gogo and CommandProcessor, etc interfaces
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, it was basically decided that there wasn't much reason to spec
Gogo, since there wasn't any real prospect for getting multiple
implementations. So, as of now, it won't be spec'ed and thus the
implementation should not be using the "spec" package name space.
-> richard
On 11/14/13 11:11 , Derek Baum wrote:
> 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 <da...@redbite.com> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo and CommandProcessor, etc interfaces
Posted by Derek Baum <de...@baums.org.uk>.
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 <da...@redbite.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>