I generally agree about optional packages in most cases I simply avoid them.
In some rare cases they are not so bad though. For example in felix system ready we used it to provide a servlet if the servlet spec is available. DS helps nicely with this so we did not have to handle ClassNotFoundException. In this case an additional bundle seemed a bit overkill especially as the code is very small at the moment. So back to my question is the manually defined import still the best practice (in case of the bad practice to use optionals :-) ? Christian Am Do., 5. Juli 2018 um 10:03 Uhr schrieb Tim Ward <tim.w...@paremus.com>: > 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 > > > 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 > > Computer Scientist > http://www.adobe.com > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
