Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
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 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 > 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 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 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 > > : > >> 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:
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
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 wrote: > > Sure. Sounds like a plan :) > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory > : >> 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 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 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 > : >> 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
Re: [VOTE][RC1] Release Commons Math 4.0-beta1
Le sam. 17 déc. 2022 à 20:27, Alex Herbert a écrit : > > Verified the checksums on the source and binary archives. > > Verified the binary jar files have the correct module entries in the > MANIFEST.MF. > > Built from the git tag using: 'mvn' > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/apache-maven-3.6.3 > Java version: 1.8.0_301, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > > Built from the tar source using: mvn site site:stage > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/apache-maven-3.6.3 > Java version: 17, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "12.6.1", arch: "x86_64", family: "mac" > > Notes on the site: Personally, I don't understand why Commons continues to link web site maintenance and a release vote (released items comprise Javadoc generated from the corresponding source). > > The developer guide on the site could do with an update to reflect > github PRs (see the numbers, rng guide etc). Adding a .gitattributes > to the repo would make redundant the developer notes on setting up git > config for line endings. OK. Done in commit 84d2c948bbb7f1d8e8db534ecb206d1358466b4a > > There is no release history page. However it does duplicate > information in the changes report. So perhaps other sites that have a > release history page should drop it. One to discuss. +1 to drop redundant info. > > The changes report has a big TBD at the top of the page. Indeed. Forgot to remove that; but I don't know that it makes any difference, as it would reappear at the next update of the site (based on the version in "master" of "changes.xml"). If we consider the "RELEASE-NOTES.txt" text file to be the "authoritative" summary of the changes in that release, the "changes" HTML report should not require adding yet another step (to clean up the file in the "release" branch) to the release process. > > The jira report is empty. I recently fixed this for BCEL which had > some very old tickets that did not have a Priority label in the > expected Major, Minor, etc. but used 1, 2, 3, etc. These were legacy > tickets ported from a Bugzilla system. Tracking them down required > locally building the maven-changes-plugin and printing out all the > tickets where the priority was returned as null, causing a NPE. Isn't that a bug in "maven-changes-plugin"? Could we fix this through JIRA? > > In the userguide overview there is no mention of the legacy module. Yes. I postponed the resolution of https://issues.apache.org/jira/browse/MATH-1604 to "4.X". > Some sort of statement that captures the intent to provide backward > compatibility for functionality in CM3 in the legacy module I indicated in the release notes what the intent really is. ;-) > and that > new code will be added into new modules would be useful. > > The overview section 0.3 has the packages: complex; distribution; > fraction; geometry. These do not exist in the code. However the links > are useful as when followed they point to the new Commons projects > containing the updated code. Sections intentionally left in (for the reason which you mention). > Perhaps the links for packages removed in > 4.0 should be placed below under a section for migrated code. I think that it is clear(er) as it is (as advertisement for the new components). [But I won't mind another layout.] > > The latest API docs link is broken as the structure is now modular. > This could be fixed using an aggregate docs module (see numbers, rng) > that builds an aggregate javadoc across the entire set of modules and > uses this in the site link for the javadoc. +1 > No real issues here, just things to tidy up. > > +1 Release it > > Alex > > On Thu, 15 Dec 2022 at 19:10, Gilles Sadowski wrote: > > > > Hello. > > > > This is a VOTE for releasing Apache Commons Math v4.0-beta1 (from RC1). > > [Thanks for the help to get there!] > > > > Tag name: > > commons-math-4.0-beta1-RC1 > > > > Command for checking out the project corresponding to this tag: > > $ git clone https://gitbox.apache.org/repos/asf/commons-math.git > > --branch commons-math-4.0-beta1-RC1 > > > > From within the "commons-math" directory created by the above command, you > > can > >1. check the tag signature with the command > > $ git tag -v commons-math-4.0-beta1-RC1 > > > >2. build the project[1] with the command > > $ mvn > > > > Tag URL: > > > > https://gitbox.apache.org/repos/asf?p=commons-math.git;a=commit;h=12ad3420a77611557603d1c7893d588610b2463a > > > > Commit ID the tag points at: > > 12ad3420a77611557603d1c7893d588610b2463a > > > > Site: > >
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
Sure. Sounds like a plan :) Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory : >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 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 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 >> > > : >> > > > 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 >> >>
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
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 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 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 > > > : > > > > 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 > >
Re: [VOTE][RC1] Release Commons Math 4.0-beta1
Verified the checksums on the source and binary archives. Verified the binary jar files have the correct module entries in the MANIFEST.MF. Built from the git tag using: 'mvn' Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /usr/local/apache-maven-3.6.3 Java version: 1.8.0_301, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" Built from the tar source using: mvn site site:stage Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /usr/local/apache-maven-3.6.3 Java version: 17, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "12.6.1", arch: "x86_64", family: "mac" Notes on the site: The developer guide on the site could do with an update to reflect github PRs (see the numbers, rng guide etc). Adding a .gitattributes to the repo would make redundant the developer notes on setting up git config for line endings. There is no release history page. However it does duplicate information in the changes report. So perhaps other sites that have a release history page should drop it. One to discuss. The changes report has a big TBD at the top of the page. The jira report is empty. I recently fixed this for BCEL which had some very old tickets that did not have a Priority label in the expected Major, Minor, etc. but used 1, 2, 3, etc. These were legacy tickets ported from a Bugzilla system. Tracking them down required locally building the maven-changes-plugin and printing out all the tickets where the priority was returned as null, causing a NPE. In the userguide overview there is no mention of the legacy module. Some sort of statement that captures the intent to provide backward compatibility for functionality in CM3 in the legacy module and that new code will be added into new modules would be useful. The overview section 0.3 has the packages: complex; distribution; fraction; geometry. These do not exist in the code. However the links are useful as when followed they point to the new Commons projects containing the updated code. Perhaps the links for packages removed in 4.0 should be placed below under a section for migrated code. The latest API docs link is broken as the structure is now modular. This could be fixed using an aggregate docs module (see numbers, rng) that builds an aggregate javadoc across the entire set of modules and uses this in the site link for the javadoc. No real issues here, just things to tidy up. +1 Release it Alex On Thu, 15 Dec 2022 at 19:10, Gilles Sadowski wrote: > > Hello. > > This is a VOTE for releasing Apache Commons Math v4.0-beta1 (from RC1). > [Thanks for the help to get there!] > > Tag name: > commons-math-4.0-beta1-RC1 > > Command for checking out the project corresponding to this tag: > $ git clone https://gitbox.apache.org/repos/asf/commons-math.git > --branch commons-math-4.0-beta1-RC1 > > From within the "commons-math" directory created by the above command, you > can >1. check the tag signature with the command > $ git tag -v commons-math-4.0-beta1-RC1 > >2. build the project[1] with the command > $ mvn > > Tag URL: > > https://gitbox.apache.org/repos/asf?p=commons-math.git;a=commit;h=12ad3420a77611557603d1c7893d588610b2463a > > Commit ID the tag points at: > 12ad3420a77611557603d1c7893d588610b2463a > > Site: > http://home.apache.org/~erans/commons-math-4.0-beta1-site/ > > Distribution files and release notes: > https://dist.apache.org/repos/dist/dev/commons/math/ > > To verify the integrity of the distribution files, you can > > 1. download them with the command > $ wget -nH --cut-dirs=8 \ > > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz > \ > > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip > \ > > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz > \ > > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip > > 2. copy/paste the following excerpt (hash of the distribution files) > into a text file (say "sha512.txt"): > ---CUT--- > # > 4a535ba815bd74eab4890d2a99ecfbe719927521b547119d68b03d87e6984f6ca41b9ee66cd4bd37bfc77762f0146227b7bd4a2157500aabfa20ce674fc9f8ab > commons-math-4.0-beta1-bin.tar.gz > 3951e7d287032cb2beb966a5259c5ce6c64830fa9570a4659e4e36b74eecfd941ccc8c729dff1b9db1d695301e6a83e2ec35e49c54520c35d93146bfcafcf024 > commons-math-4.0-beta1-bin.zip > 668f552c444c7328bfb4e73bfba031e00d56212fc38a5d587ac9809ae63547b1caec7edb46a808dd62054601aaca696c3afa9fc4b6e5daa38d8c0db0f31a2ccd >
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
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 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 > > : > > > 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
Re: Any plans to release DBUtils anytime soon?
One of the PRs you merged broke the build on GitHub, please fix. Gary On Mon, Dec 5, 2022, 09:40 Carl Hall wrote: > Hi, all! I'm working through the PR backlog and correcting build errors. > Once I get things settled, I'll return to the 2.0 release from a couple of > years ago to cancel & restart that motion. > > On Tue, Nov 8, 2022 at 12:30 PM Gary Gregory > wrote: > > > And for the curious my plan for a release train is: BCEL, Net, Crypto, > CSV, > > Pool, DBCP, Configuration. > > > > Gary > > > > On Tue, Nov 8, 2022, 12:27 Gary Gregory wrote: > > > > > I can only give the usual response: We are unpaid volunteers with > limited > > > time and priorities that may not align with what you might be > > specifically > > > looking for. > > > > > > Gary > > > > > > On Tue, Nov 8, 2022, 11:45 mkpaz wrote: > > > > > >> Hello! > > >> > > >> It's been awhile since DBUtils last release in 2017. There was a lot > of > > >> good work done. Could you please share why it's > > >> not getting updates. Any blocking issues? > > >> > > >> Mike. > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > >
