I’ve not used it so not sure but would this help any in migrating the namespace?
https://github.com/apache/tomcat-jakartaee-migration Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla <rich...@zowalla.com > (mailto:rich...@zowalla.com)> wrote: > Sure. Sounds like a plan :) > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory > <garydgreg...@gmail.com (mailto: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 > > (mailto: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 > > > > (mailto: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 (mailto: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 > > > > > > (mailto:dev-unsubscr...@commons.apache.org) > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > (mailto:dev-h...@commons.apache.org) > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > (mailto:dev-unsubscr...@commons.apache.org) > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > (mailto:dev-h...@commons.apache.org) > > > > > >
