On Mon, Oct 22, 2018 at 8:47 AM Guillaume Nodet <gno...@apache.org> wrote:
> Afaik, gogo supports overriden methods, so you can have multiple methods > for a single command (for example the "cd" command). > I'm not sure that adding this metadata to the function name will be very > easy. > > Maybe a possible way would be to have a json file containing the metadata > in a know location so that the "help" command could load them on demand and > have them generated by a maven plugin at build time ? > That sounds interesting! It does force gogo into having to fetch the bundle from the ServiceReference in order to fetch the resources, but I don't think that's a deal breaker. Any other opinions? - Ray > > Le lun. 22 oct. 2018 à 05:59, Raymond Auge <raymond.a...@liferay.com> a > écrit : > > > Hey all, > > > > In a recent conversation with Thomas Watson we touched on moving some > > commands into their implementation bundles. For instance, log commands > > should be in the log service impl, etc. > > > > However we don't want to lose the @Descriptor & @Parameter features to > > describe the commands. On the other hand, we should not be coupled to the > > `org.apache.felix.service.command` package. > > > > My first notion was to use Bundle annotations, but obviously those are > not > > visible at runtime when the command processor handles the commands. > > > > Then I was thinking of encoding the information as either an additional > > service property on the command service. However the alignment, > > particularly, with the property `osgi.command.function`, which is an > array, > > makes this a little weird. > > > > Then I thought maybe we could extend the encoding of > > `osgi.command.function` to use the OSGi package syntax which would > continue > > to make any existing values compatible (since they would be just keys, > > while allowing for additional "attributes", such as description and > > parameters to be added. It's certainly not perfect. > > > > Anyone have thoughts on ways of encoding this? > > > > -- > > *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) > > > > > -- > ------------------------ > Guillaume Nodet > -- *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)
