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)
