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