I think a json or text based approach is essential. It’s been a while but as I recall in DS with annotated commands, I could not find any way to make the information from the annotations available to gogo if DS started before gogo; once the command class was loaded without the gogo annotations there was no way to go back and get the annotations. Perhaps someone has solved this problem since, but any code complexity around this is silly.
david jencks > On Oct 21, 2018, at 11:55 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > On Mon, Oct 22, 2018 at 8:47 AM Guillaume Nodet <gno...@apache.org > <mailto: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 > <http://www.liferay.com/web/raymond.auge/profile>> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com > <http://www.liferay.com/>> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org > <http://osgi.org/>> (@OSGiAlliance)
