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 >
