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