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 >
