Thank you Felix, I agree and understand all of what you are saying. However, what I'm wondering though is if anyone has come up with a design pattern where a DS component can determine programmatically whether it (or a peer component it controls) should be provided as a service based on the check for some optional package.
Sincerely, - Ray On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > 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>: > > 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 > 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 > -- *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 https://mail.osgi.org/mailman/listinfo/osgi-dev
