When a dependency has provided scope, it is available at build time, but not at runtime. It is also not contributed to the runtime classpath when another module is depending on the module which has a declared provided dependency. This choice by the Jsoup authors indicate it's build time only
Also, those annotations (NotNull, Nullable etc) are meant for an IDE, that can detect certain API-misusage at source level (build level), like explicit passing a null object (the IDE can figure out the object is always null at that point) as a parameter, when the API is annotated @NotNull. Anyway, I tried embedding the dependency in a service, and I removed the problematic import and then I let the service do JSoup.connect() and get the title of a webpage. My service was still satisfied and JSoup was able to do what I requested. So instead of embedding you can simply do a re-pack and remove the unwanted import. Guava is another example, it has all these code analysis dependencies that OSGi often wants to be provisioned, but can be omitted. - Eric L On Wed, Aug 25, 2021 at 6:37 PM Steinar Bang <[email protected]> wrote: > >>>>> Steinar Bang <[email protected]>: > > >> Is there a workaround, other than re-bundling jsoup? > > > One workaround would be to load version 3.0 (or so) of the glassfish > > packaged javax.annotation...? > > > Since the packages are versioned it shouldn't conflict with the felix > > version...? > > > (but it just feels so hacky...) > > FWIW what I've done, for now, is to put a <scope>compile</scope> > dependency to the findbugs jar in the pom files that have the > <scope>compile</scope> dependency to jsoup. > > Again, FWIW, this seems to work. > > The one package that also exist in the felix runtime (javax.annotation), > have a different version, and a version matching jsoup, so they > shouldn't conflict...? > > >
