felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: svn commit: r952918 - in /felix/trunk: gogo/commands/ gogo/commands/src/main/java/org/apache/felix/gogo/commands/ gogo/commands/src/main/java/org/apache/felix/gogo/commands/basic/ gogo/commands/src/main/java/org/apache/felix/gogo/commands/convert
Date Wed, 23 Jun 2010 13:14:34 GMT
On Wed, Jun 23, 2010 at 14:31, Richard S. Hall <heavy@ungoverned.org> wrote:
> On 6/23/10 5:45, Guillaume Sauthier wrote:
>>
>> Hi guys
>>
>> Maybe I react after the battle but, I was quite happy with the commands
>> module in gogo :)
>> I thought it was really some kind of extension to the gogo framework, not
>> so closely related to karaf.
>>
>> We're using it in a chameleon subproject [1] to provide commands/actions
>> as iPOJO components.
>> And we're definitely not depending on karaf, but on gogo.
>>
>> Is it possible to move back that module into gogo or at least discuss the
>> issue ?
>
> Even if it is in Karaf, there is nothing that prevents you from using it
> from there. I'm sure it will continue to be released as a separate module,
> so it doesn't really matter if the groupId is org.apache.felix or
> org.apache.karaf.
>
> Ultimately, the commands module was ported from previous Karaf/ServiceMix
> Kernel work and didn't completely fit the Gogo model, which isn't about
> registering Function services as commands, but rather ordinary Java objects.
> So, it doesn't seem fitting for Gogo to promote an approach that isn't the
> intended approach.

That's your view of gogo and please bear in mind your view is not always
everyone's view nor the only possible view.   The
org.osgi.service.command package
defines 4 interfaces, one of them being Function.  I can't possibly imagine how
you can assert that this interface has been designed not to be used.

If you don't want to use it, that's fine.  I don't see why this has to
be *the* way ...
And please, don't say people are free to do it another way, because that's what
you're trying to rule out by pushing this one into the api and pushing
out the gogo
the previous commands module.


> The RFC behind Gogo is still changing too, so the impl will change to
> reflect it. There is some effort to provide similar capabilities in the core
> RFC as to what the commands module provided, e.g., annotations for
> describing commands. Hopefully, as it progresses it will subsume the
> capabilities of the commands module, but if not, nothing prevents you from
> continuing to use the old version of the commands module (unless there is
> some backwards incompatible change).
>
> -> richard
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message