Is there a way to break this into 2 parts - the pure api and the implementation?
Downstream frameworks (like Spring & Quarkus) may want to use their own Jackson versions & their own http implementations. Using the client as-is does not allow for this customization.
I maintain the Docling Java client and we have successfully done that - separated into 2 artifacts, the api & the client. Downstream frameworks like Spring & Quarkus only depend on the API and provide their own implementations of it. See https://github.com/docling-project/docling-java/tree/main/docling-serve
The Docling api also supports both Jackson 2 & 3 simultaneously.
We use a ServiceLoader abstraction, so you never actually have to use the implementation imports directly. Everything is driven through the API.
Apps that use Jackson 3 are unable to use this api at all.
I'm happy to help contribute if there is interest.
Is there a way to break this into 2 parts - the pure api and the implementation?
Downstream frameworks (like Spring & Quarkus) may want to use their own Jackson versions & their own http implementations. Using the client as-is does not allow for this customization.
I maintain the Docling Java client and we have successfully done that - separated into 2 artifacts, the api & the client. Downstream frameworks like Spring & Quarkus only depend on the API and provide their own implementations of it. See https://github.com/docling-project/docling-java/tree/main/docling-serve
The Docling api also supports both Jackson 2 & 3 simultaneously.
We use a
ServiceLoaderabstraction, so you never actually have to use the implementation imports directly. Everything is driven through the API.Apps that use Jackson 3 are unable to use this api at all.
I'm happy to help contribute if there is interest.