felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Gogo commands module (Was: 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/apa
Date Wed, 23 Jun 2010 14:14:33 GMT
We actually did discuss that on skype.   The initial thoughts were to
modify and reuse all the existing karaf commands and make them a bit
more generic, and at some point you found some naming issues on the
interface and annotations defined. I was not aware you were to rewrite
everything from scratch.  I guess that happened after you discussed
with Peter, but i wasn't in the loop.  You then pushed your new
annotations in svn and those still don't address some features we need
in karaf (completion is the most important that comes to my mind if
you ask), so we can't even migrate to those.
So now, we moved this bits back into karaf as requested, which is not
a problem in itself (I just wasted a few days working on extracting
this module just to move it back a few months later).  I guess the
problem is that we now have two different sets of commands and karaf
can't even be upgraded to the new gogo version because the package as
been renamed to org.apache.felix (instead of splitting the existing
org.osgi.service.command package that had been published from the new
annotations you added).
I'm still not sure what we'll do in the coming weeks about that.

As for the RFC, those changes have not shown up into the latest
document, so I'm waiting for an update so that we can at last discuss

On Wed, Jun 23, 2010 at 15:57, Richard S. Hall <heavy@ungoverned.org> wrote:
> On 6/23/10 9:45, Guillaume Nodet wrote:
>> On Wed, Jun 23, 2010 at 15:37, Richard S. Hall<heavy@ungoverned.org>
>>  wrote:
>>> On 6/23/10 9:14, Guillaume Nodet wrote:
>>>> 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 reality is this:
>>>  1. When I started to use Gogo, I tried to use the commands module
>>>     first. I found it very cumbersome and unintuitive.
>>>  2. I talked with some people about using Gogo and none of them were
>>>     using the commands module and specifically Peter Kriens told me
>>>     that the Function interface was really only intended for closures
>>>     and whatnot and that I should just be using objects with methods.
>>>  3. Following Peter's advice, I tried to create commands the way he
>>>     suggested, which led to other shortcomings which were corrected by
>>>     the addition of some annotations, which were created in concert
>>>     with Peter. After that, things went swimmingly.
>>>  4. Given that the commands module didn't fit this view and no one was
>>>     using it besides Karaf, it seemed to make sense to move it out of
>>>     the Gogo subproject.
>>> You may feel that this is forcing out the commands module, but that
>>> certainly wasn't the case given that's where I started. I am not sure why
>>> you feel having a separate module is such a bad thing, since that's the
>>> whole point of OSGi.
>> Well, I guess I may have a different view if all of that would have
>> happened publicly on the dev list and not using backchannels.
> Considering I discussed the issues I was having with you directly and we
> created a JIRA issue for the removal commands module, I hardly think this
> was backchannels.
> Still, if you are really going to get your undies in a bunch, we can move it
> back, but its groupId will need to be changed to "org.apache.felix" and it
> will need a new artifactId to avoid confusion with the "command" module that
> provides commands, any suggestions?
> In the end, it will still be the same as having it be a Karaf module, since
> Gogo modules will get released independently just like every other
> subproject (i.e., there is no such thing as a "Gogo distribution release").
> Nor does it seem likely that that the Karaf approach will be supported by
> the RFC itself. So, if everyone agrees that its worthwhile to have the Karaf
> command approach be a module in the Gogo subproject directory, we can do
> that.
> -> richard
>>> And, for the record, I do think it makes more sense for Gogo itself to
>>> promote a single way of creating commands, unless the alternative
>>> approaches
>>> are completely compatible with each other and in this case they aren't
>>> really compatible with each other.
>>> ->  richard
>>>>> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message