PS: for ref, the original thread on this topic https://markmail.org/message/76uveuuvvhxx6b3v
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 à 20:25, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > > > 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 >> >
