I can only say, that I fully agree with Romain here. For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to let the users fork/relocate or abandon dbcp2 in order to be able to use the jakarta.* namespace.
The EE ecosystem is moving and if we want to play a role in it, we need to adapt a bit. That said, it isn't a huge effort to migrate / create a version to support jakarta.* IMHO it is only a matter of available resources / time and people/volunteers who want to contribute / help to make it happen. If it requires to make a dbcp3 due to commons rule set (binary compat) and relocation isn't an option, so be it. Nevertheless, I would appreciate some perspective, so we can deal with it on our side :-) (and as already said: I am happy to help / contribute, if needed) Gruß Richard On 2022/12/18 16:08:57 Romain Manni-Bucau wrote: > Le dim. 18 déc. 2022 à 12:04, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > What's the rush? Commons has never been on the bleeding edge of anything. > > > > > Java and EE release rates changed - as well as spring baseline. If commons > sticks to the old one it is harder (impossible) to use directly. > Today dbcp is either forked/relocated or abandonned for that reason so > guess we should either adapt the release rate and testing coverage to these > changes or freeze the project if it is no more matching end users envs. > > > You saw the plan I proposed I presume. > > > > Yep but with no (even vague) date it does not mean much to me, just "we > dont care of last two majors of EE" until something happens. > This is why I ask what does mean a little and when dbcp3 would be a thing. > Would also be important to document it and maybe recommend tomcat-jdbc for > user until we support jakarta. > > > > > Gary > > > > > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > Any idea on when it can occurs? We are quite late to the party already > > and > > > shade was a good solution to be in without additional cost in terms of > > > maintainance for the project so if not the picked option we should target > > > some point not too far in 2023 pby. > > > > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > Hi Arun, > > > > > > > > There's not going to be anything to pick up for a while ;-) > > > > > > > > Gary > > > > > > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan <arun.avanat...@gmail.com> > > > > wrote: > > > > > > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it > > > up. > > > > > > > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla <rich...@zowalla.com> > > > > > wrote: > > > > > > > > > > > > Sure. Sounds like a plan :) > > > > > > > > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory < > > > > > garydgreg...@gmail.com>: > > > > > >> I think we should wait for a little while: I'd want to release > > > current > > > > > code > > > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool), > > > make > > > > > sure > > > > > >> all is well, then see about going to DBCP 3, on Java 8 for now but > > > > > >> considering Java 11 maybe. Do consider that the Commons community > > is > > > > > small > > > > > >> and I would not want to support concurrent support and releases on > > > > bothe > > > > > >> DBCP 2 and 3. > > > > > >> > > > > > >> Gary > > > > > >> > > > > > >> Gary > > > > > >> > > > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla <r...@apache.org> > > > wrote: > > > > > >>> > > > > > >>> For DBCP, it basically boils down to > > > > > >>> > > > > > >>> BasicManagedDataSource.java > > > > > >>> DataSourceXAConnectionFactory.java > > > > > >>> LocalXAConnectionFactory.java > > > > > >>> SynchronizationAdapter.java > > > > > >>> TransactionContext.java > > > > > >>> TransactionRegistry.java > > > > > >>> > > > > > >>> Looking at these classes, the move to jakarta definitley affects > > > > binary > > > > > >>> compatibility as we have changes in return types / arguments of > > > > public > > > > > >>> methods. Given that it breaks binary compatibility, we could even > > > > > >>> increase the java level to 11 and drop deprecated things in a > > > > potential > > > > > >>> dbcp 3. > > > > > >>> > > > > > >>> In the end, I am happy with everything, which brings DBCP into > > the > > > > > >>> Jakarta world ;) > > > > > >>> > > > > > >>> If we have consensus for a route, I am happy to work on it / make > > > it > > > > > >>> happen via related PRs but would need some guideance on the best > > > way > > > > to > > > > > >>> move forward. > > > > > >>> > > > > > >>> Gruß > > > > > >>> Richard > > > > > >>> > > > > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain > > > Manni-Bucau: > > > > > >>>> If not done in new classes (both can live in the same lib > > > > > >>>> technically), > > > > > >>>> sadly yes. > > > > > >>>> > > > > > >>>> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla < > > > rich...@zowalla.com> > > > > a > > > > > >>>> écrit : > > > > > >>>> > > > > > >>>>> Thanks for your replies. > > > > > >>>>> > > > > > >>>>> I guess, that switching the namespace leads to binary > > > > > >>>>> incompatibility (If > > > > > >>>>> I take the definition from [1]). I cannot drop it in a running > > > JVM > > > > > >>>>> / app > > > > > >>>>> and expect no issues with it as the related APIs are breaking > > > > > >>>>> namespace > > > > > >>>>> changes (at least at runtime if they aren't present) :-) > > > > > >>>>> > > > > > >>>>> Aside from that fact, method signatures might also change from > > > > > >>>>> javax -> > > > > > >>>>> jakarta, which would require a short investigation and usage of > > > the > > > > > >>>>> existing tooling to see if this happens. > > > > > >>>>> > > > > > >>>>> From a commons point of view that would mean to go for dbcp3, > > > > > >>>>> right? > > > > > >>>>> > > > > > >>>>> Gruß > > > > > >>>>> Richard > > > > > >>>>> > > > > > >>>>> [1] > > > > > >>>>> > > > > > >>> > > > > > > > > > > > > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > > >>>>> > > > > > >>>>> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas > > > > > >>>>> <ma...@apache.org>: > > > > > >>>>>> On 16/12/2022 13:24, Gary Gregory wrote: > > > > > >>>>>>> Thank you Richard for starting this thread. > > > > > >>>>>>> > > > > > >>>>>>> My view is simpler perhaps: I would not make this about the > > > > > >>>>>>> javax vs > > > > > >>>>>>> Jakarta namespaces. > > > > > >>>>>>> > > > > > >>>>>>> I don't want to double the numbers of jars we produce from > > the > > > > > >>>>>>> same > > > > > >>>>> branch > > > > > >>>>>>> for affected components as one of the scheme proposed. It > > feels > > > > > >>>>>>> like a > > > > > >>>>>>> burden to maintenance moving forward and a very brittle > > process > > > > > >>>>>>> with > > > > > >>>>> some > > > > > >>>>>>> unforeseen side effects. > > > > > >>>>>>> > > > > > >>>>>>> This is just a code change IMO. For a given component, either > > > > > >>>>>>> it is > > > > > >>>>> binary > > > > > >>>>>>> compatible, or it is not. You don't know until you try it and > > > > > >>>>>>> see if > > > > > >>>>> public > > > > > >>>>>>> and protected elements break, using our existing > > configuration > > > > > >>>>>>> of Maven > > > > > >>>>> and > > > > > >>>>>>> japicmp (or revapi). > > > > > >>>>>>> > > > > > >>>>>>> If it is binary compatible, then let's consider making the > > > > > >>>>>>> change. If > > > > > >>>>> not, > > > > > >>>>>>> then do it in a major version, where the previous major > > version > > > > > >>>>>>> is > > > > > >>>>>>> maintained as we do now, as need be. > > > > > >>>>>>> > > > > > >>>>>>> A new major version also benefits from the usual dropping of > > > > > >>>>>>> deprecated > > > > > >>>>>>> elements and making any other changes with seem reasonable. > > > > > >>>>>> > > > > > >>>>>> +1. I don't see this as any different to increasing the > > minimum > > > > > >>>>>> version > > > > > >>>>> of Java and supported new JDBC methods. > > > > > >>>>>> > > > > > >>>>>> Mark > > > > > >>>>>> > > > > > >>>>>> > > > ----------------------------------------------------------------- > > > > > >>>>>> ---- > > > > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > >>>>>> > > > > > >>>>> > > > > > >>> > > > > > >>> > > > > > >>> > > > --------------------------------------------------------------------- > > > > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > >>> > > > > > >>> > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
