-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't embed slf4j-api and jsr305 in flying-saucer-pdf-osgi #403
Comments
@kwin I am not an expert in OSGI, but shouldn't we just remove ![]() |
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 |
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. @kwin Do you have any ideas how to solve this issue? |
Neither SLF4J or JSR305 should be transitively needed at compile time for consumers of flying saucer. |
Any of SLF4J implementations includes slf4j-api anyway.
Any of SLF4J implementations includes slf4j-api anyway.
Thanks a lot for the quick fix. |
Version 9.9.5 of
org.xhtmlrenderer.flying.saucer.pdf.osgi
embeds the following JARs: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.
The text was updated successfully, but these errors were encountered: