Hi You mean dynamic imports due to optional dependencies ?
I think the key is to limit them. If I remember correctly I have (or had) some of this in the Apache Felix SCR implementation around the Metatype and Configuration Admin dependencies. What I do is I hand-craft a DynamicImport-Package statement for the exact package along with the packages import version range. Then, unless the service is provided, the package may not be resolved. I generally also have fields, but as long as I don’t access that field other than checking for null, the dependency is not needed either. This works great, but I try to reduce such uses to the absolute minimum because it involves manual work. Hope this helps Regards Felix Am 25.04.2017 um 14:10 schrieb Raymond Auge <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>>: I'm wondering if there is a reasonable model for handling optional or dynamic package imports in DS. While optionality at the package level is not an ideal model, sometimes it can't be avoided. I'd like to know if others have come across a "reasonable" way to model this in DS. Sincerely, -- 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) _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
