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.
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. 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
