Le lun. 19 déc. 2022 à 16:25, Eric Bresie <ebre...@gmail.com> a écrit :
> I’ve not used it so not sure but would this help any in migrating the > namespace? > > https://github.com/apache/tomcat-jakartaee-migration It is strictly equivalent to the shade option but requires maven build helper plugin to attach the relocated artifact so not sure since we fall in the same option categories. > > > 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) > > > > > > > > >
