That was the problem I left the code base with:-) I think I recall seeing one of my failed attempts to solve it removed with a comment that made me hope someone had found a way to successfully deal with the situation; apparently not. I had thought that if the command class was loaded only after the annotations were available then they’d get imported and used, but couldn’t figure out a way to make that happen.
A couple of questions about the proposal…. Is gogo related to an osgi spec? I thought not…. in which case using osgi.command.function in the property name is perhaps not appropriate. How about including the method signature in the property name rather than just the method name? I think this would make the properties approach as powerful as annotations. How about preprocessing the annotations into properties? In whatever form, I still think this is a good idea… David Jencks > On Feb 17, 2019, at 8:37 AM, Thomas Watson <[email protected]> wrote: > > The problem is if scr is not resolved against the optional import for the > command package then the annotations are unrecognized by the gogo runtime. > So if scr is resolved before the gogo bundles are installed we get no help. > > Tom > > On Sat, Feb 16, 2019, 7:20 PM David Jencks <[email protected] wrote: > >> Well, I like this idea. >> >> To dilute the thread,.... when I worked on the ds gogo commands, if ds >> started before the gogo annotations were available the gogo commands worked >> but had no “help”. Has anyone succeeded in solving this problem? Is this >> the sort of problem you’re proposing to solve here? >> >> Thanks >> David Jencks >> >> Sent from my iPhone >> >>> On Feb 16, 2019, at 3:44 PM, Raymond Auge <[email protected]> >> wrote: >>> >>> I'll take the resounding silence as everyone holding their breath in >>> anticipation. >>> >>> Thx, >>> - Ray >>> >>> On Wed, Feb 13, 2019 at 9:45 AM Raymond Auge <[email protected]> >>> wrote: >>> >>>> Hello everyone, >>>> >>>> A few months ago we discussed a way of describing Gogo Command functions >>>> without being bound by the gogo APIs (i.e. using the annotations). >>>> >>>> Recently the issue of being optionally bound to the Gogo runtime API >>>> actually caused the Equinox project some issues with their adoption of >>>> Felix SCR as its DS implementation. >>>> >>>> I've personally struggled with the issue at my company as well. >>>> >>>> In order to aleviate this coupling, Tom Watson and I have a proposal to >>>> simplify the common case (i.e. NOT as a full replacement for the >>>> annotations): >>>> >>>> The proposal is to support a _fall back to service properties_ for >> missing >>>> @Descriptor annotation, like so: >>>> >>>> - @Descriptor on TYPE = service.description >>>> - @Descriptor on METHOD = osgi.command.function.<name> >>>> - @Descriptor on PARAMETER = osgi.command.function.<name>.param.# >> (indexed >>>> from 0) >>>> >>>> Note that overloaded methods lead to ambiguity in this model. Our >> proposal >>>> is NOT to solve that. Rather, if you have such a complex case, use the >>>> annotations. >>>> >>>> Thoughts? Anyone object to making this enhancement? >>>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>> (@Liferay) >>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>> (@OSGiAlliance) >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >>
