Don't embed slf4j-api and jsr305 in flying-saucer-pdf-osgi

[kwin]

Version 9.9.5 of org.xhtmlrenderer.flying.saucer.pdf.osgi embeds the following JARs:

1. flying-saucer-pdf-9.9.5.jar
2. openpdf-2.0.3.jar
3. jsr305-3.0.2.jar
4. slf4j-api-2.0.16.jar

The latter two should not be embedded as JSR305 is not necessary at run time at all. SLF4J on the other hand always relies on both the API and the impl. Just embedding the API is not enough (https://www.slf4j.org/manual.html#swapping). As the SLF4J provider/impl bundle also has a dependency on the API it is safe to import the SFL4J API in flying-saucer-pdf-osgi as well. That way you can also ensure that the provider version is compatible with the API version used in flying saucer.

[asolntsev]

@kwin I am not an expert in OSGI, but shouldn't we just remove scope=compile from the build script?

[kwin]

Usually you use scope provided for all dependencies supposed to be externally provided (in OSGi this means by other bundles) and compile for things which are embedded

[asolntsev]

Right. Well, I meant that we should mark "jsr305" and "slf4j-api" as "compile only" dependencies: needed for compilation, but not needed in runtime. And it seems Maven doesn't provide such a scope (while Gradle has; Gradle is better ;) ).

A very similar scope to "compileOnly" in Maven is "provided", but it doesn't work because it's not transient. If we mark "jsr302" as "provided", user's project will not compile anymore as described in https://github.com/flyingsaucerproject/flyingsaucer/issues/260.

@kwin Do you have any ideas how to solve this issue?

[kwin]

Neither SLF4J or JSR305 should be transitively needed at compile time for consumers of flying saucer.

[kwin]

Thanks a lot for the quick fix.