FYI we run jakarta tck now with https://issues.apache.org/jira/browse/OWB-1327 As expected it works fine
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 lun. 8 juin 2020 à 08:33, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <cgurkanerdo...@gmail.com> a > écrit : > >> > Not, it is not correct Gurkan ;). >> > jakarta does NOT support OSGi properly, it does it the old way and break >> > several rules. For instance last CDI spec jar contains: >> >> As I said in my previous email, I am not an OSGI expert. But, what I can >> do >> is that I can ping the CDI team in EE4J to add features to support >> OWB-OSGI >> or other ASF projects? Could you explain in detail? >> > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;) > It is mainly the metadata. > Point is we already contacted the spec leaders, even for Microprofile if > you want to get the full story (same people more or less) and it didn't go > well enough even if people were willing to do it. > So factually today it is saner to keep it here and it is not an issue for > G project anyway since we do it for years and we will keep doing it for > defaults at least. > Once again not an OWB discussion and decision had been taken already on > this one so don't want to loop on the same topic again and again, in > particular from the wrong list ;). > > >> >> Regards. >> Gurkan >> >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <cgurkanerdo...@gmail.com> >> wrote: >> >> > So to conclude on this point not belonging to OWB, we still need our >> fork >> >> and eclipse always answered saying "yes we want OSGi [but we don't >> really >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't >> >> work on that factually so OSGi is done at minimal cost. >> > >> > OK thanks for the clarification. I am not an OSGI expert. >> > >> > Ok Gurkan, let's be concrete, do you - you as you personally - accept >> and >> >> commit yourself to port any commit to one of the two branches to the >> other >> >> for all the time the project is at apache? >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by >> facts) >> >> work. >> > >> > :=) >> > Hey, I'm just proposing what I think about. If nobody cares about it or >> > is not beneficial, it is ok, and also there is no need to VOTE (This is >> why >> > I'd like to get more opinions on it). But look at Weld, they did the >> > update, https://github.com/weld and full of updating their pom to use >> > jakarta.* >> > >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use >> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will >> > eventually move to jakarta.* namespace. Instead of working with such >> > shading plugin stuff as a workaround, I just offer to take the master to >> > jakarta.* and update all OWB modules' dependency from javax.* to >> jakarta.* >> > official APIS. This is not related to who will maintain the branches. >> You >> > know that ASF works as a voluntary based approach. You can not push >> anybody >> > to work on anything as in commercial companies. >> > >> > Also, regarding the cost and energy you mention to maintain the branch, >> > via Geronimo specs, you will need to update all of the Geronimo Specs >> and >> > maintain them. I think this is not rational because now, jakarta.* >> official >> > API license is EPL and Apache friendly. Why do I need to maintain for >> > example Geronimo EL? >> > >> > Regards. >> > Gurkan >> > >> > >> > >> > >> > >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cgurkanerdo...@gmail.com> >> a >> >> écrit : >> >> >> >> > Hi David >> >> > >> >> > I’m not sure exactly how it impacts this decision, but IIUC the >> geronimo >> >> > > cdi spec jar is rather essential for some uses as it has OSGI >> support >> >> > > whereas IIUC the eclipse/jakarta one doesn’t. >> >> > > >> >> > No, it is not correct. It has OSGI support. GlassFish is an OSGI >> based >> >> > server.You can grap the code from >> https://github.com/eclipse-ee4j/cdi >> >> and >> >> > build. It has OSGI enabled MANIFEST.MF file. >> >> > >> >> >> >> Not, it is not correct Gurkan ;). >> >> jakarta does NOT support OSGi properly, it does it the old way and >> break >> >> several rules. For instance last CDI spec jar contains: >> >> >> >> Manifest-Version: 1.0 >> >> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo >> >> r Java) >> >> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api >> >> Built-By: default >> >> Bnd-LastModified: 1590678420932 >> >> Bundle-ManifestVersion: 2 >> >> Bundle-DocURL: https://jboss.org >> >> Bundle-Vendor: JBoss by Red Hat, Inc. >> >> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0, >> >> 3)",jakarta.interceptor;version="[2.0,3)" >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" >> >> Tool: Bnd-2.4.1.201501161923 >> >> Originally-Created-By: Apache Maven Bundle Plugin >> >> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr >> >> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e >> >> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver >> >> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak >> >> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve >> >> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject >> >> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u >> >> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u >> >> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje >> >> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri >> >> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak >> >> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar >> >> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar >> >> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3 >> >> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja >> >> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr >> >> ise.util",jakarta.enterprise.util;version="3.0" >> >> Bundle-Name: CDI APIs >> >> Bundle-Version: 3.0.0.M4 >> >> Build-Jdk-Spec: 1.8 >> >> Created-By: Apache Maven Bundle Plugin >> >> Build-Jdk: 1.8.0_202 >> >> >> >> Where are the osgi.serviceloader and osgi.contract ? >> >> This is important and used by OSGi-CDI for example (even if it can be >> >> worked around). >> >> >> >> So to conclude on this point not belonging to OWB, we still need our >> fork >> >> and eclipse always answered saying "yes we want OSGi [but we don't >> really >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't >> >> work on that factually so OSGi is done at minimal cost. >> >> >> >> >> >> > >> >> > Gurkan’s proposal will only add difficulty for developers and >> probably >> >> > > users. >> >> > > >> >> > What is the difficulty? The change will only affect maintaining the >> >> javax.* >> >> > branch and fully renamed jakarta.* dependencies in master. >> >> > >> >> >> >> Ok Gurkan, let's be concrete, do you - you as you personally - accept >> and >> >> commit yourself to port any commit to one of the two branches to the >> other >> >> for all the time the project is at apache? >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by >> facts) >> >> work. >> >> >> >> >> >> > >> >> > Regards. >> >> > Gurkan >> >> > >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks < >> david.a.jen...@gmail.com> >> >> > wrote: >> >> > >> >> > > I’m not sure exactly how it impacts this decision, but IIUC the >> >> geronimo >> >> > > cdi spec jar is rather essential for some uses as it has OSGI >> support >> >> > > whereas IIUC the eclipse/jakarta one doesn’t. >> >> > > >> >> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT >> >> > Gurkan’s >> >> > > proposal will only add difficulty for developers and probably >> users. >> >> > > Although I haven’t been active here for years I might even vote. >> >> > > >> >> > > thanks >> >> > > David Jencks >> >> > > >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu < >> >> cgurkanerdo...@gmail.com> >> >> > > wrote: >> >> > > > >> >> > > >> >> >> > > >> Tomcat works with branches since years without any issue. >> >> > > >> All projects we tried to use branches we abandoned branches just >> >> after >> >> > > >> having done them. >> >> > > >> It is fine if the old branch is no more used but here we know we >> >> will >> >> > > >> maintain javax branch more than jakarta one for some time so I >> >> think >> >> > we >> >> > > >> should avoid it while it is not justified or one of the 2 >> branches >> >> > > (javax) >> >> > > >> is "almost dead". >> >> > > > >> >> > > > Working with branches always happens in all open source projects. >> >> And >> >> > > > there are times when it is logical to create the branch. Jakarta >> EE >> >> 9 >> >> > API >> >> > > > migration is the best time to create such a branch. Eventually, >> we >> >> will >> >> > > > create such a branch in Jakarta EE 10. >> >> > > > >> >> > > > Fact there will be no more javax is useless IMHO, only question >> we >> >> > should >> >> > > >> care about is "do we have javax users?" and should we work on >> >> javax >> >> > > branch >> >> > > >> enough to care about having 2 duplicate branches. Answer is >> >> obviously >> >> > > yes >> >> > > >> and more than jakarta users today, therefore I think for some >> >> months >> >> > > (maybe >> >> > > >> a few years) we should stick to javax as our primary branch and >> >> ensure >> >> > > the >> >> > > >> alignments and bugfixes can trivially - == without any action >> from >> >> dev >> >> > > - be >> >> > > >> ported. It is what we have today. >> >> > > >> >> >> > > > What could be more natural than maintaining branches (with >> >> backporting >> >> > > from >> >> > > > master only if necessary). With Jakarta EE 10, we will eventually >> >> > create >> >> > > > the branch for supporting the EE 8. Also, for the release >> >> versioning, >> >> > it >> >> > > is >> >> > > > nice to have a 3.x release. The community will notice that 3.x is >> >> the >> >> > > > starting point of Jakarta EE support. Will you release 2.x with >> the >> >> > > > intention of supporting Jakarta EE 9? I am personally not >> positive >> >> on >> >> > > this. >> >> > > > I think, 3.x release will also get more interest even if the >> >> > > functionality >> >> > > > and API stay the same. We can prepare the press release for it. >> >> > > > >> >> > > > Note we shouldn't depend on jakarta/javax api anyway (neither as >> >> > groupId >> >> > > >> nor as transitive dep so this change must stay a noop for >> >> consumers). >> >> > > >> >> >> > > > What is the problem of depending on the official Jakarta EE CDI >> >> API? It >> >> > > is >> >> > > > an Apache friendly license. Instead of maintaining the Geronimo >> CDI >> >> API >> >> > > > internally, it is more logical to use Jakarta EE official CDI API >> >> and >> >> > > > maintain this API with EE4J community. >> >> > > > >> >> > > > would also appreciate if you do a vote if you can point out the >> >> > breaking >> >> > > >> changes - except the package renaming - justifying to fork >> ourself >> >> and >> >> > > what >> >> > > >> does not work with current solution, can ease the decision/vote. >> >> > > >> Today using jakarta/EE9 API is quite easy ( >> >> > > >> >> >> > > >> >> > >> >> >> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt >> >> > > >> ). >> >> > > >> We should absolutely enhance the pom experience though but it is >> >> > > trivial to >> >> > > >> do at maven level - I was envisionning to do it in shade plugin >> to >> >> be >> >> > > more >> >> > > >> precise. >> >> > > >> >> >> > > > I know that there will be no functional change. But, I am also >> >> against >> >> > > > shading for jakarta.*. If there will be no change on Jakarta EE >> 10, >> >> > will >> >> > > we >> >> > > > continue to shade? What happens when there will be a change in >> EJB, >> >> > JMS >> >> > > > etc specifications but no change in CDI in Jakarta EE 10? Also, >> >> VOTING >> >> > is >> >> > > > the natural thing to do for the community decision. If the >> community >> >> > > would >> >> > > > like to keep it as it is via shading, it is fine. >> >> > > > >> >> > > >> >> >> > > >> To try to rephrase/clarify my questionning today: you ask for >> >> jakarta >> >> > > >> support, we already have it in a dev and project efficient way >> so >> >> why >> >> > > >> should we change since I don't hink there is anything new - once >> >> again >> >> > > if >> >> > > >> API starts to fully break discussion is different but github >> doesnt >> >> > > reflect >> >> > > >> that? >> >> > > >> >> >> > > > This is not just for Jakarta EE 9 support. As we know, there will >> >> be no >> >> > > API >> >> > > > (functional) change, only package renaming. But, I want to >> emphasize >> >> > that >> >> > > > with such turning points, it is so logical to integrate official >> >> > Jakarta >> >> > > > CDI API into our master (removing the geronimo-cdi), and release >> our >> >> > new >> >> > > > 3.x version and let the public know that OWB supports official >> CDI >> >> API >> >> > > > beginning with 3.x release. Yeah, shading is an option for >> package >> >> > > renaming >> >> > > > but think long term. Also, I am really against the shading. It >> >> really >> >> > > > disturbs the users which depend on OWB implementation. For >> example, >> >> > > > currently Glassfish supports Weld integration but one can also >> >> > implement >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of using the >> >> > shaded >> >> > > > version, it is really important to have the full Jakarta EE CDI >> API >> >> in >> >> > > our >> >> > > > poms. You will still have javax.* dependency in ur POMs even if >> >> doing a >> >> > > > shade. This is not good idea to still maintain javax.* in our POM >> >> > files. >> >> > > > >> >> > > > What are other opinions before formal voting? >> >> > > > Regards. >> >> > > > Gurkan >> >> > > > >> >> > > > >> >> > > > >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau < >> >> > rmannibu...@gmail.com >> >> > > > >> >> > > > wrote: >> >> > > > >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu < >> >> cgurkanerdo...@gmail.com >> >> > > >> >> > > a >> >> > > >> écrit : >> >> > > >> >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on >> >> > master. >> >> > > >>> >> >> > > >> >> >> > > >> Tomcat works with branches since years without any issue. >> >> > > >> All projects we tried to use branches we abandoned branches just >> >> after >> >> > > >> having done them. >> >> > > >> It is fine if the old branch is no more used but here we know we >> >> will >> >> > > >> maintain javax branch more than jakarta one for some time so I >> >> think >> >> > we >> >> > > >> should avoid it while it is not justified or one of the 2 >> branches >> >> > > (javax) >> >> > > >> is "almost dead". >> >> > > >> >> >> > > >> >> >> > > >>> sorry but not understand the resistance on this? will you >> always >> >> > shade >> >> > > ? >> >> > > >>> >> >> > > >> >> >> > > >> As mentionned, until API needs changes we can't easily handle - >> >> today >> >> > > there >> >> > > >> is no change. >> >> > > >> >> >> > > >> >> >> > > >>> creating the new master and maintain the 2.x branch, is the >> best >> >> > > logical >> >> > > >>> way. there will be no javax.* any more. Tomcat maintains 3 >> >> branches >> >> > > and >> >> > > >> 1 >> >> > > >>> master. only maintains 1 branch and 1 master is totally fine. >> >> > > >>> >> >> > > >> >> >> > > >> Fact there will be no more javax is useless IMHO, only question >> we >> >> > > should >> >> > > >> care about is "do we have javax users?" and should we work on >> >> javax >> >> > > branch >> >> > > >> enough to care about having 2 duplicate branches. Answer is >> >> obviously >> >> > > yes >> >> > > >> and more than jakarta users today, therefore I think for some >> >> months >> >> > > (maybe >> >> > > >> a few years) we should stick to javax as our primary branch and >> >> ensure >> >> > > the >> >> > > >> alignments and bugfixes can trivially - == without any action >> from >> >> dev >> >> > > - be >> >> > > >> ported. It is what we have today. >> >> > > >> >> >> > > >> >> >> > > >>> >> >> > > >>> I will propose a vote shortly to decide on to create a master >> with >> >> > 3.x >> >> > > >> with >> >> > > >>> fully support of jakarta with a normal pom dependency with >> jakarta >> >> > api. >> >> > > >>> >> >> > > >> >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as >> >> > groupId >> >> > > >> nor as transitive dep so this change must stay a noop for >> >> consumers). >> >> > > >> I would also appreciate if you do a vote if you can point out >> the >> >> > > breaking >> >> > > >> changes - except the package renaming - justifying to fork >> ourself >> >> and >> >> > > what >> >> > > >> does not work with current solution, can ease the decision/vote. >> >> > > >> Today using jakarta/EE9 API is quite easy ( >> >> > > >> >> >> > > >> >> > >> >> >> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt >> >> > > >> ). >> >> > > >> We should absolutely enhance the pom experience though but it is >> >> > > trivial to >> >> > > >> do at maven level - I was envisionning to do it in shade plugin >> to >> >> be >> >> > > more >> >> > > >> precise. >> >> > > >> >> >> > > >> To try to rephrase/clarify my questionning today: you ask for >> >> jakarta >> >> > > >> support, we already have it in a dev and project efficient way >> so >> >> why >> >> > > >> should we change since I don't hink there is anything new - once >> >> again >> >> > > if >> >> > > >> API starts to fully break discussion is different but github >> doesnt >> >> > > reflect >> >> > > >> that? >> >> > > >> >> >> > > >> >> >> > > >>> >> >> > > >>> Regs >> >> > > >>> Gurkan >> >> > > >>> >> >> > > >>> >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau < >> >> rmannibu...@gmail.com >> >> > > >> >> > > >>> wrote: >> >> > > >>> >> >> > > >>>> Today we don't need, tomorrow I don't know but while API does >> not >> >> > > >> change >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it >> is >> >> > what >> >> > > >> you >> >> > > >>>> propose as a consequence). >> >> > > >>>> If it becomes necessary let's do it but my vote is to stay >> lazy >> >> on >> >> > > >> that. >> >> > > >>>> >> >> > > >>>> >> >> > > >>>> side note for G API discussion belongs to dev@G but it is >> less >> >> an >> >> > > >> issue >> >> > > >>> to >> >> > > >>>> fork from now since we rarely update the API, the side note >> here >> >> is >> >> > > >> that >> >> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta >> >> package >> >> > > >> since >> >> > > >>>> some weeks or months, we did all the needed releases. >> >> > > >>>> >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko < >> >> > > >>>> andraschko.tho...@gmail.com> >> >> > > >>>> a écrit : >> >> > > >>>> >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our >> build. >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine. >> >> > > >>>>> >> >> > > >>>>> I'm actually also a supporter of doing a hard cut but it's >> not >> >> > > >> required >> >> > > >>>> and >> >> > > >>>>> we can do it for EE 10. >> >> > > >>>>> >> >> > > >>>>> < >> >> > > >>>>> >> >> > > >>>> >> >> > > >>> >> >> > > >> >> >> > > >> >> > >> >> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> >> > > >>>>>> >> >> > > >>>>> Virenfrei. >> >> > > >>>>> www.avast.com >> >> > > >>>>> < >> >> > > >>>>> >> >> > > >>>> >> >> > > >>> >> >> > > >> >> >> > > >> >> > >> >> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> >> > > >>>>>> >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> > > >>>>> >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu < >> >> > > >>>>> cgurkanerdo...@gmail.com>: >> >> > > >>>>> >> >> > > >>>>>> We need to maintain two branches >> >> > > >>>>>> >> >> > > >>>>>> EE 8 for javax.* package 2.x branch >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master >> >> > > >>>>>> >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau < >> >> > > >> rmannibu...@gmail.com >> >> > > >>>> >> >> > > >>>>>> wrote: >> >> > > >>>>>> >> >> > > >>>>>>> Hi, >> >> > > >>>>>>> >> >> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings >> >> > > >>>>> significatively >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but >> I >> >> can >> >> > > >>> have >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can >> stay >> >> as >> >> > > >> we >> >> > > >>>> are >> >> > > >>>>> I >> >> > > >>>>>>> think avoiding to maintain two branches we can't merge >> >> regularly. >> >> > > >>>>>>> >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu < >> >> > > >>>> cgurkanerdo...@gmail.com> >> >> > > >>>>> a >> >> > > >>>>>>> écrit : >> >> > > >>>>>>> >> >> > > >>>>>>>> Hi >> >> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to >> >> > > >> support >> >> > > >>>>>> upcoming >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace? >> >> > > >>>>>>>> >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of >> using >> >> the >> >> > > >>>>> Apache >> >> > > >>>>>>>> based api. >> >> > > >>>>>>>> Regards >> >> > > >>>>>>>> Gurkan >> >> > > >>>>>>>> >> >> > > >>>>>>>> -- >> >> > > >>>>>>>> Gurkan Erdogdu >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com >> >> > > >>>>>>>> >> >> > > >>>>>>> >> >> > > >>>>>> -- >> >> > > >>>>>> Gurkan Erdogdu >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com >> >> > > >>>>>> >> >> > > >>>>> >> >> > > >>>> >> >> > > >>> -- >> >> > > >>> Gurkan Erdogdu >> >> > > >>> http://gurkanerdogdu.blogspot.com >> >> > > >>> >> >> > > >> >> >> > > > >> >> > > > >> >> > > > -- >> >> > > > Gurkan Erdogdu >> >> > > > http://gurkanerdogdu.blogspot.com >> >> > > >> >> > > >> >> > >> >> > -- >> >> > Gurkan Erdogdu >> >> > http://gurkanerdogdu.blogspot.com >> >> > >> >> >> > >> > >> > -- >> > Gurkan Erdogdu >> > http://gurkanerdogdu.blogspot.com >> > >> >> >> -- >> Gurkan Erdogdu >> http://gurkanerdogdu.blogspot.com >> >
