@Gary: I agree with the plan but as Romain outlined, it requires some details / perspective.
Am Montag, dem 19.12.2022 um 21:33 +0100 schrieb Romain Manni-Bucau: > @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-perfor > mance> > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
