+1 The only fuzz johnzon can create as of today is that we relocate javax -> jakarta but not johnzon -> org.apache.johnzon.jakarta (to enable a future transparent transition), but as mentionned, if you use both at the same time it can't work as of today but guess having both at the same time is a rare case - even TomEE never has this case.
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 à 21:49, Clebert Suconic <clebert.suco...@gmail.com> a écrit : > thing is Spring and Wildfly they are removing all libraries that have > anything to do with javax..... and I'm not sure if I provide a jakarta > library if that would create any fuss.. > > > it doesn't make sense to me either. other than users wanting that... > > > let me clear that with some guys on spring and wildfly to see if I > could just use jakarta... > > > thanks for the help... I will figure out this first. > > On Thu, Nov 11, 2021 at 3:21 PM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > 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 > > > > > > > -- > Clebert Suconic >
