Skip to content
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

Closed
kwin opened this issue Oct 4, 2024 · 5 comments · Fixed by #410
Closed

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

kwin opened this issue Oct 4, 2024 · 5 comments · Fixed by #410
Assignees
Labels
dependencies Pull requests that update a dependency file
Milestone

Comments

@kwin
Copy link

kwin commented Oct 4, 2024

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
Copy link
Contributor

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

image

@kwin
Copy link
Author

kwin commented Oct 5, 2024

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
Copy link
Contributor

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 #260.

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

@kwin
Copy link
Author

kwin commented Oct 6, 2024

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

@asolntsev asolntsev added this to the 9.10.0 milestone Oct 10, 2024
asolntsev added a commit that referenced this issue Oct 10, 2024
Any of SLF4J implementations includes slf4j-api anyway.
@asolntsev asolntsev linked a pull request Oct 10, 2024 that will close this issue
@asolntsev asolntsev self-assigned this Oct 10, 2024
@asolntsev asolntsev added the dependencies Pull requests that update a dependency file label Oct 10, 2024
asolntsev added a commit that referenced this issue Oct 10, 2024
Any of SLF4J implementations includes slf4j-api anyway.
@kwin
Copy link
Author

kwin commented Oct 10, 2024

Thanks a lot for the quick fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants