Given it happens at runtime, then it means the import is already in your net.leangen.expedition.platform.ddd.diag bundle, so it's just the consequence of a problem happening at build time. And this means, either a class import the package, or there is an explicit instruction to import it either in the bundle plugin config or in a bnd file. Last possibility is that the bundle being built embeds code from a different jar, and that code has a class which import the package. As for blacklisting, you can urls in the etc/blacklisted.properties file, but it seems the problem comes from your own net.leangen.expedition. platform.ddd.diag bundle...
2017-10-10 0:03 GMT+02:00 David Leangen <apa...@leangen.net>: > > > > On Oct 9, 2017, at 4:23 PM, Achim Nierbeck <bcanh...@googlemail.com> > wrote: > > > On Oct 9, 2017, at 4:28 PM, Guillaume Nodet <gno...@apache.org> wrote: > > Thanks for the suggestions. You are no doubt right, so I quadruple checked > my code, and bumped all versions. Ran the build locally, and confirmed that > the old package is not being pulled in… but it still gets pulled in during > resolution in Karaf. > > Two questions: > > 1. Is there a mechanism to trace back the results of the resolution so I > can try to pinpoint where the bad package is being pulled in? > > 2. Is it possible to blacklist in Karaf, so I can avoid a particular > version of a bundle or package? (I did not see anything in the docs.) > > > Thanks! > =David > > > -- ------------------------ Guillaume Nodet
