One of the big challenges with optional imports is that they are so rarely actually optional, and that they end up not being wired to you in future if the dependency becomes available as a result of a later bundle installation
Every time I see an optional import it tells me that the bundle has poor cohesion, and should probably be split into two bundles, one containing the “optional” piece as a mandatory import. Then if you want the optional behaviour you install the optional bundle, and don’t have to worry about handling optional packages. Optional packages are also often misused as a “pluggable” mechanism where you can use one of a set of libraries to provide a piece of function. In this case each individual library is “optional” but you must have at least one of them for your bundle to work. This results in bundles with broken metadata which will resolve even when they can’t run. Again the plug point should be implemented with a mandatory package dependency supplied by a bundle with a mandatory dependency on one of the bundles, ideally using a service. Even if you do have a truly optional package dependency you need to do lots of error-prone reflective access with try/catch blocks, and have a Dynamic-Import for it as well. In summary, optional packages are a bad thing, and I don’t think that we should be encouraging people to use them. Instead we should be encouraging people to write cohesive modular bundles which therefore do not need optional imports. Best Regards, Tim P.S. This is the same advice that I have given for years - see from slide 30 of this (rather old) lightning talk https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward <https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward> > On 5 Jul 2018, at 07:41, Christian Schneider via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > I am currently looking into improving the OSGi setup of bundles. > > For package exports I have found the package-info.java to be the best > practice (see below): > > @org.osgi.annotation.versioning.Version("1.0.0") > @org.osgi.annotation.bundle.Export > package my.package; > > Imports are normally computed automatically. Some cases that still need > special handling are changes in import range or optional imports. > > Currently I use this for optional imports: > > bnd.bnd > Import-Package: \ > javax.servlet*;resolution:=optional,\ > * > > Is this still best practice or do we have something better? The > maven-bundle-plugin makes imports optional if the maven dependency is > optional. Is there a way to make the bnd-maven-plugin to behave in the same > way? Any better solution? > > Thanks > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de <http://www.liquid-reality.de/> > > Computer Scientist > http://www.adobe.com <http://www.adobe.com/> > > _______________________________________________ > 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
