> > When required we'll do, today there is really nothing justifying it.
If one integrates the OWB via POM dependency in his jakarta project, it is a problem to see javax.* everywhere in OWB POM files. He needs to solve problems via some exotic POM operations. For example, I did not able to run TEstNG Probably, you will do it shortly because Jakarta EE 10 will start Anyway, keep the good work. Also, we need to extend the community around OWB. Community projects grow with community and decisions are made by the community. Gurkan On Wed, Jun 10, 2020 at 12:08 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le mer. 10 juin 2020 à 09:55, Gurkan Erdogdu <cgurkanerdo...@gmail.com> a > écrit : > > > 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. > > > > We did :) > > > > 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) > > > > Well in front of that I can say "I don't see any reason to use jakarta > artifacts". > Both are true except we control G ones, we don't control jakarta one and it > happens they have bugs. > We - at asf - also generally run with G ones so it is better to harness G > ones than jakarta ones. > It is not a big +1 for G but a +0.1 and -0.1 for jakarta. > Finally, since we don't really provide these artifacts in owb itself it > does not change anything but we do in meecrowave (an owb project - and here > it is not a choice since we must have the right defaults) so it is > consistent to use the same accross projects of the same family IMHO. > > > > 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. > > > > When required we'll do, today there is really nothing justifying it. > > > > 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 > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
