Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <clebert.suco...@gmail.com> a écrit :
> We provide javax and jakarta libraries for our client libraries. > > and Johnzon is used internally at some places, but it's not really > part of the API. > > So, certain users when embedding Artemis into their server want to use > only jakarta libraries. > > Our server does not need the library to be jakarta, so if we had a > org.apache.johzon.api instead, it would make our life easier on my own > distribution of both libraries. > Have to admit it does not make much sense after some thought+testing cause if so, isnt javax as org.apache.johnzon for a jakarta server (and the opposite too)? For servers supporting both it is not an issue too. So Im quite puzzled to see any case a 3rd distro would help any user out of "i dont want javax" which is as arbitrary as "i dont want apache". What I think we must not do is a facade on top of javax/jakarta in our core cause it will be a mess in a few version when well drop javax support. If it is internal for artemis, why not just moving to jakarta? Will not break javax users until they use johnzon for both and if so, dropping yasson for the "other" impl is a workaround until both namespaces are merged in jakarta for the app. Overall my point is that javax is dead so it is just a migration step so we shouldnt have a core module abstracting both. Fine if we do a johnzon-javax-jakarta-abstraction new module we drop in 3-4 years. Is it what you want? Do you want to PR it? Guess we dont need reflection at all using a small reflection check of the provider implemented classes and a proxy based impl for interfaces - personally i would go with asm generation but any impl working for you with a low overhead is fine. > > On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > 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 > > > > > > > -- > Clebert Suconic >
