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