What's the rush? Commons has never been on the bleeding edge of anything. You saw the plan I proposed I presume.
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 > > > > > > > > >
