Yeah.. I don't need both at the same time...but I have to develop artemis clients for Jakarta and for Javax.
so, I'm fixing that by creating my own shading of javax.json on my artemis-commons client for now.... which I will remove it in a few years when we stop supporting javax. libraries... This javax and jakarta names is a mess... geez! Thanks for the help again On Fri, Nov 12, 2021 at 1:51 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > +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 > > -- Clebert Suconic
