Hi Clebert,

What is the goal? Use org.apache.johnzon.api instead of a portable API? I'm
fine doing another shade - as javax/jakarta one - in
org.apache.johnzon.apix or any package helping if it is the idea - but not
sure I fully got the actual issue since from my window artemis must provide
a jakarta and a javax version of its impl - as all EE libs - so it could
likely be saner to solve it with a shade of artemis itself - thinking loud
to JMS first and JSON* as a consequence more than an issue by itself.

Hope I'm not too off the actual issue.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 11 nov. 2021 à 18:32, Clebert Suconic <clebert.suco...@gmail.com> a
écrit :

> As the core implementation is hard coded towards javax.json, Artemis
> requires using javax.json libraries as we use
>
> However we have users that require jakarta APIs, and since our server
> implementation relies on javax.json, we would need to provide a shaded
> version of our server as well.
>
> And this is honestly getting out of hand. We already provide shaded
> client libraries.. but now users want the dependency switch optionally
> on the server's as well.
>
> Can't we refactor the core implementation to have public
> implementations without requiring javax.json or jakarta.json? and then
> having a facade on top of the implementation for each binding?
>
>
>
> --
> Clebert Suconic
>

Reply via email to