On Mon, Oct 22, 2018 at 8:03 AM Guillaume Nodet <gno...@apache.org> wrote:
> 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. > > > > Using an optional import should be fine. This should not prevent loading > the classes even if the annotations are not present at runtime. > Optional imports are terrible! Dynamic import sure... the point is that it's not very nice "contract" for services particularly because there's no specific type related to the command services. > This looks the easiest option to me. > Could you explain what problems you see in it ? I don't really understand. > I don't think I can convince Equinox folks, or any other projects that want clean dependencies, to import the package period. - Ray > > > > > > 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)
