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 >