@gary: you likely need to refine your plan to make it a plan and not a discussion proposal, ie put some date. If you want to release dbcp2 this year and move to dbcp3 in january for a 1.0.0 (or whatever version) in early february I guess it works for everyone. If it is about waiting 1-2 months to get 2 out, 3-4 months to get 3 out it means we loose one more year in terms of adoption and I guess we would be closer to my point that dbcp will never met jakarta as of today where hikaricp and tomcat-jdbc are used by default when upgrading stacks since jakarta adoption will accelerate next year with spring 6 hard move and related migrations. If it is the kind of time frame I guess the relocation - shade or tomcat tool - will be a better option for commons and the project (it is the option geronimo/openwebbeans/meecrowave/tomee adopted with success to ensure a single branch was to maintain before the final switch which should occur when javax branch is definitively dead for end users - should happen in a few years, maybe 2-3 due to first jakarta release time and usual adoption rate).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 19 déc. 2022 à 21:23, Gary Gregory <garydgreg...@gmail.com> a écrit : > I feel like we're going around in circles. Do you not agree my the > path I previously outlined? > > Gary > > On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla <r...@apache.org> wrote: > > > > I can only say, that I fully agree with Romain here. > > > > For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 > (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to > let the users fork/relocate or abandon dbcp2 in order to be able to use the > jakarta.* namespace. > > > > The EE ecosystem is moving and if we want to play a role in it, we need > to adapt a bit. That said, it isn't a huge effort to migrate / create a > version to support jakarta.* > > > > IMHO it is only a matter of available resources / time and > people/volunteers who want to contribute / help to make it happen. If it > requires to make a dbcp3 due to commons rule set (binary compat) and > relocation isn't an option, so be it. > > > > Nevertheless, I would appreciate some perspective, so we can deal with > it on our side :-) (and as already said: I am happy to help / contribute, > if needed) > > > > Gruß > > Richard > > > > > > > > On 2022/12/18 16:08:57 Romain Manni-Bucau wrote: > > > Le dim. 18 déc. 2022 à 12:04, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > What's the rush? Commons has never been on the bleeding edge of > anything. > > > > > > > > > > > > > Java and EE release rates changed - as well as spring baseline. If > commons > > > sticks to the old one it is harder (impossible) to use directly. > > > Today dbcp is either forked/relocated or abandonned for that reason so > > > guess we should either adapt the release rate and testing coverage to > these > > > changes or freeze the project if it is no more matching end users envs. > > > > > > > > > You saw the plan I proposed I presume. > > > > > > > > > > Yep but with no (even vague) date it does not mean much to me, just "we > > > dont care of last two majors of EE" until something happens. > > > This is why I ask what does mean a little and when dbcp3 would be a > thing. > > > Would also be important to document it and maybe recommend tomcat-jdbc > for > > > user until we support jakarta. > > > > > > > > > > > > > Gary > > > > > > > > > > > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau < > rmannibu...@gmail.com> > > > > wrote: > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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 > >
