The example that you’ve just given is an excellent candidate for splitting into two bundles. Small bundles are not a sign of bad code, just well-purposed code. Having the servlet in there is a smell because it’s unrelated to the actual purpose of the bundle (namely providing a ready service). It really looks like the purpose of the servlet is to be a plugin for the web console (why else would you use system/console in the pattern), at which point this really should be a separate bundle!
> So back to my question is the manually defined import still the best practice > (in case of the bad practice to use optionals :-) ? Yes, you do it by putting "resolution:=optional” against the import in your bnd file. Then you look at it, decide it’s ugly, then refactor your bundle so that you don’t need the optional import any more. :-) Tim > On 5 Jul 2018, at 12:39, Christian Schneider <ch...@die-schneider.net> wrote: > > 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 > <mailto: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 > <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 <mailto: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 <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > -- > -- > 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
