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 ? Le lun. 22 oct. 2018 à 05:59, Raymond Auge <[email protected]> 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
