This javax to jakarta has already created problems in running for example TestNG tests in eclipse :) Also, keep in mind that OWB also depends on several Geronimo EE APIs and must be sure that there is no String usage of javax. in any of these APIs. I am still not convinced of using shaded artifacts. For me the best thing is to do one big single conversion from javax. to jakarta. and create a branch and also using Jakarta EE APIs. I don't see any reason to use Geronimo APIs. (except some simple OSGI artifacts) As I see, there are no other opinions, I will not create a VOTE for this and keep this way. But, it will finally need to be done. Gurkan
On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko < andraschko.tho...@gmail.com> wrote: > Nice work romain! > > Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > 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 > > >> > > > > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
