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