On Wed, Jun 23, 2010 at 15:37, Richard S. Hall <[email protected]> wrote: > On 6/23/10 9:14, Guillaume Nodet wrote: >> >> On Wed, Jun 23, 2010 at 14:31, Richard S. Hall<[email protected]> >> 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. > 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 >>> >>> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
