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 >
