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