Re: [Lang] "CalendarUtilsTest" fails, or not...
This could be caused by tests occurring in random order. If there is a test that changes the global locale, and fails to reset it, behaviour will depend on when the failing test is run in relation to others. If you still have the logs, try comparing the order of tests. On Wed, 7 Dec 2022 at 01:34, Gary Gregory wrote: > > Interesting, the GH builds are green: > https://github.com/apache/commons-lang/actions > > But the environment is different from yours: > > Maven home: /usr/share/apache-maven-3.8.6 > Java version: 11.0.17, vendor: Eclipse Adoptium, runtime: > /usr/lib/jvm/temurin-11-jdk-amd64 > Default locale: en, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-1023-azure", arch: "amd64", family: > "unix" > > Gary > > On Tue, Dec 6, 2022, 19:18 Gilles Sadowski wrote: > > > Hello. > > > > Running > > $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test > > [... skipped ...] > > [ERROR] Failures: > > [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6> > > [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: > > <340> > > [INFO] > > [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7 > > [...] > > > > > > Running > > $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn > > -Dtest=CalendarUtilsTest test > > [... skipped ...] > > [INFO] Running org.apache.commons.lang3.time.CalendarUtilsTest > > [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > > 0.089 s - in org.apache.commons.lang3.time.CalendarUtilsTest > > [INFO] > > [INFO] Results: > > [INFO] > > [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 > > [...] > > > > Environment: > > $ mvn -v > > Apache Maven 3.6.3 > > Maven home: /usr/share/maven > > Java version: 11.0.16, vendor: Debian, runtime: > > /usr/lib/jvm/java-11-openjdk-amd64 > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "linux", version: "5.10.0-17-amd64", arch: "amd64", family: "unix" > > > > Regards, > > Gilles > > > > - > > 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: Math: Yearly patch for commons-math3
Le mer. 7 déc. 2022 à 08:23, Jochen Wiedmann a écrit : > > Hi, David, > > if you want to be sure, that commons-math3 is being maintained, To be clear, "Commons Math" (CM) v3.x has not been maintained for years now (since it was *agreed* to develop a new major version) in accordance with the policy followed by the CM team since its inception. > then I > suggest that you take a look at the Git repository log. That should be > sufficient: > > https://gitbox.apache.org/repos/asf?p=commons-math.git;a=log Dozens of bug fixes and performance improvements are available from * the now released components spun off from CM, and * the CM "master" branch (towards v4.0). Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Lang] "CalendarUtilsTest" fails, or not...
Le mer. 7 déc. 2022 à 10:04, sebb a écrit : > > This could be caused by tests occurring in random order. If there is a > test that changes the global locale, and fails to reset it, behaviour > will depend on when the failing test is run in relation to others. If > you still have the logs, try comparing the order of tests. Attached in JIRA report: https://issues.apache.org/jira/browse/LANG-1693 Regards, Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1
On Tue, 6 Dec 2022 at 12:21, Gilles Sadowski wrote: > > > > So the issue with staging the RC site to home.apache.org does not > > apply when staged to the commons.apache.org. > > > > You could perhaps (FTR) file a JIRA issue to INFRA. Since I had deleted the site from my home area I uploaded it again. Now the previous issue with rendering the distribution module pages is not present (see [1]). So I have nothing to show INFRA. Alex [1] https://home.apache.org/~aherbert/commons-statistics-1.0-site/commons-statistics-distribution/index.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Apache Commons Statistics Version 1.0 Released
The Apache Commons Team is pleased to announce the availability of version 1.0 of "Apache Commons Statistics". Apache Commons Statistics provides tools for statistics. This is the first release of Apache Commons Statistics. Contains the following modules: commons-statistics-distribution. Requires Java 8. For complete information on Apache Commons Statistics, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Statistics website: https://commons.apache.org/proper/commons-statistics/ Distribution packages can be downloaded from http://commons.apache.org/proper/commons-statistics/download_statistics.cgi When downloading, please verify signatures using the KEYS file available at https://www.apache.org/dist/commons/KEYS The Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[rng] LGTM switch to CodeQL GH action
The [rng] project was signed up to LGTM.com analysis (I presume at their website). This is now being decommissioned. The underlying analysis engine is CodeQL and this is migrating to direct support as a Github action. Do we want to continue with this for [rng]? There is a PR open by their bot to enable it [1]. AFAICR the analysis has never noticed any issues. We get far more feedback from using the sonarcloud analysis that is run by the Jenkins CI build [2]. I compared their recommended GH workflow to the one configured to [lang]. It appears mostly the same. I note that both ask for write permission to the security events. I do not know how this fits with the security policy to not publicly disclose events until reviewed and patched, i.e. I do not know if the security tab for the GH page is restricted, and where event notifications will be sent. So I do not want to enable this without further investigation, unless someone can confirm what exactly the CodeQL build analysis will do if it finds something. Alex [1] https://github.com/apache/commons-rng/pull/119 [2] https://sonarcloud.io/project/overview?id=commons-rng - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Main site is outdated
So I can see the file to edit is index.html at this location: svn checkout --depth files https://svn.apache.org/repos/infra/websites/production/commons/content/ But should this be edited manually, or is it generated/updated via some automation? I ask as the newly released statistics component entry requires more than just a version number to be updated. The entire link and badge requires adding. Alex On Tue, 6 Dec 2022 at 23:58, Gilles Sadowski wrote: > > Le mer. 7 déc. 2022 à 00:31, sebb a écrit : > > > > On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski wrote: > > > > > > Hello. > > > > > > Homepage > > >https://commons.apache.org/ > > > contains inconsistent information: Some "(maven-central) badges" display > > > a version number but the link points to another (usually older) one. See > > > e.g. > > > * RNG > > > * Geometry > > > * Imaging > > > * Numbers > > > * Compress > > > * Pool > > > * JCS > > > * Math > > > * Configuration > > > * Text > > > * Net > > > * ... > > > > That's because the version data has not been updated in the relevant > > status file. > > RMs should ensure that the file is updated upon release. > > > > The badges are generated dynamically from Maven Central metadata, so > > are whatever the image.shields.io website thinks is the latest. > > > > IMO these invisible dynamic queries go against the Privacy FAQ: > > > > https://privacy.apache.org/faq/committers.html > > > > I think it would be better to have a regular batch job to ensure the > > status file is up to date and not rely on a 3rd party. > > > > Sorry, I'm fairly lost here; I don't know what "image.shields.io" is. > Nor when/how we started having those links/badges generated. > > I seem to remember that the RM had to update this file: > > https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties > and the appropriate file in > https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/ > > But then? Is there a script to run so that the site is updated? > > > Gilles > > - > 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
Release Commons Fileupload 1.4.1?
Hi folks, would it be possible to release Commons Fileupload 1.4.1? 1.4 still contains commons-io 2.2 and requires to explicitly exclude it (CVE-2021-29425). Thanks, Dennis - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Fileupload 1.4.1?
This is unlikely to happen for only a dependency update, and also since it is simple to override in Maven, Ivy, and so on. Recall that we are volunteers here where each person spends their valuable time as they best see fit ;-) Gary On Wed, Dec 7, 2022, 10:49 Dennis Kieselhorst wrote: > Hi folks, > > would it be possible to release Commons Fileupload 1.4.1? 1.4 still > contains commons-io 2.2 and requires to explicitly exclude it > (CVE-2021-29425). > > Thanks, > Dennis > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
RE: Re: Release Commons Fileupload 1.4.1?
Well this is the change I'm particularly interested in to have clean transitive dependencies but looking at the commit logs other useful things happened as well. The last release happened in 2019. I understand though that fileupload is implemented differently nowadays and maintaining this project no longer is a priority. Dennis On 2022/12/07 16:01:48 Gary Gregory wrote: > This is unlikely to happen for only a dependency update, and also since it > is simple to override in Maven, Ivy, and so on. > Recall that we are volunteers here where each person spends their > valuable time as they best see fit ;-) > > Gary > > On Wed, Dec 7, 2022, 10:49 Dennis Kieselhorst wrote: > > > Hi folks, > > > > would it be possible to release Commons Fileupload 1.4.1? 1.4 still > > contains commons-io 2.2 and requires to explicitly exclude it > > (CVE-2021-29425). > > > > Thanks, > > Dennis > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: Release Commons Fileupload 1.4.1?
The next release will be 2.0 which will hopefully happen Q1 2023. Gary On Wed, Dec 7, 2022, 11:28 Dennis Kieselhorst wrote: > Well this is the change I'm particularly interested in to have clean > transitive dependencies but looking at the commit logs other useful > things happened as well. The last release happened in 2019. I understand > though that fileupload is implemented differently nowadays and > maintaining this project no longer is a priority. > > Dennis > > > On 2022/12/07 16:01:48 Gary Gregory wrote: > > This is unlikely to happen for only a dependency update, and also > since it > > is simple to override in Maven, Ivy, and so on. > > Recall that we are volunteers here where each person spends their > > valuable time as they best see fit ;-) > > > > Gary > > > > On Wed, Dec 7, 2022, 10:49 Dennis Kieselhorst wrote: > > > > > Hi folks, > > > > > > would it be possible to release Commons Fileupload 1.4.1? 1.4 still > > > contains commons-io 2.2 and requires to explicitly exclude it > > > (CVE-2021-29425). > > > > > > Thanks, > > > Dennis > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[VOTE][LAZY] Release Apache Commons Parent 55 based on RC1
We made some enhancements since Apache Commons Parent 54 was released, so I would like to release Apache Commons Parent 55. This is the parent POM for Apache Commons, it doesn't contain Java code, and therefore no JApiCmp API compatibility check or report on the site. Apache Commons Parent 55 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1 (svn revision 58537) The Git tag commons-parent-55-RC1 commit for this RC is 1a8382d227787216d76c1fea62b641158d0a265e which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=1a8382d227787216d76c1fea62b641158d0a265e You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-55-RC1 commons-parent-55-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1611/org/apache/commons/commons-parent/55/ These are the artifacts and their hashes: #Release SHA-512s #Wed Dec 07 14:37:02 EST 2022 commons-parent-55-bom.json=e96e4d8f44b900ae5b12abbf81c1fa9a5c28e13c0767290e85c0f9e0486c9b3d2f6dac6ba8f4ca3f25c00716b5b6c180f16e0cfa17a51b1fd3c63c57f13deded commons-parent-55-bom.xml=11bdf25c251b8b99f5684740e05fa08e8ad01dddeb6544327083696a578bc48785a8d27d03cd7b1ce8f3ace8f4e1b60d32819e4a3b6bc1ed775be5d549e32d33 commons-parent-55-site.xml=735ffceca46a0574d430b4e1213a2462b9475143c0788913312b8af117eaf3b7c02a075aaf6d9b30d2560822339651cb511b838f6c9f2bced46de1fc1227c5ff commons-parent-55-src.tar.gz=1a0307090faca60eaf8a034201521262828c283c8e51dd92a1add0adf48bb55898e0d990daa407648e7b65d6e85a7629ecfb30f4195fbc47d6bf0d14e9664254 commons-parent-55-src.zip=13c5158f0957853e1df39aa5aa03180b404caa727fef276c969bc811de1e6b3b5465341d544869b338597805b085c21fee63b3d2f6f42dd93dd297fe5e6c8cda org.apache.commons_commons-parent-55.spdx.json=14f27b64c60287116e84e2ae9b4d66017260287962c29baef621e9e2b06c06578768453a05bafa90cbe1aa2fe04e248aaedf9b64e8683c658452dedd798e8538 I have tested this with 'mvn clean install' using: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /usr/local/Cellar/maven/3.8.6/libexec Java version: 1.8.0_352, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac" Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64 Details of changes since 54 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1/site/index.html (note some *relative* links are broken and the 55 directories are not yet created - these will be OK once the site is deployed.) RAT Report: https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, garydgregory, Release Manager (using key DEADBEEF) For following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-55-RC1 commons-parent-55-RC1 cd commons-parent-55-RC1 1b) Download and unpack the source archive from: https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1/source 2) Check Apache licenses This step is not required if the site includes a RAT report page which you then must check. mvn apache-rat:check 3) Check binary compatibility Older components still use Apache Clirr: This step is not required if the site includes a Clirr report page which you then must check. mvn clirr:check Newer components use JApiCmp with the japicmp Maven Profile: This step is not required if the site includes a JApiCmp report page which you then must check. mvn install -DskipTests -P japicmp japicmp:cmp 4) Build the package mvn -V clean package You can record the Maven and Java version produced by -V in your VOTE reply. To gather OS information from a command line: Windows: ver Linux: uname -a 5) Build the site for a single module project Note: Some plugins require the components to be installed instead of packaged. mvn site Check the site reports in: - Windows: target\site\index.html - Linux: targe
Re: [All] Main site is outdated
On Wed, 7 Dec 2022 at 13:20, Alex Herbert wrote: > > So I can see the file to edit is index.html at this location: > > svn checkout --depth files > https://svn.apache.org/repos/infra/websites/production/commons/content/ > > But should this be edited manually, or is it generated/updated via > some automation? That URL is where the website is served; when the site is built from source it will be overwritten. The actual site source is here: https://svn.apache.org/repos/asf/commons/cms-site/trunk/ There is some documentation here: https://commons.apache.org/site-publish.html > I ask as the newly released statistics component entry requires more > than just a version number to be updated. The entire link and badge > requires adding. That needs to be done here I think: https://svn.apache.org/repos/asf/commons/cms-site/trunk/content/xdoc/index.xml.vm > Alex > > On Tue, 6 Dec 2022 at 23:58, Gilles Sadowski wrote: > > > > Le mer. 7 déc. 2022 à 00:31, sebb a écrit : > > > > > > On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski wrote: > > > > > > > > Hello. > > > > > > > > Homepage > > > >https://commons.apache.org/ > > > > contains inconsistent information: Some "(maven-central) badges" display > > > > a version number but the link points to another (usually older) one. > > > > See e.g. > > > > * RNG > > > > * Geometry > > > > * Imaging > > > > * Numbers > > > > * Compress > > > > * Pool > > > > * JCS > > > > * Math > > > > * Configuration > > > > * Text > > > > * Net > > > > * ... > > > > > > That's because the version data has not been updated in the relevant > > > status file. > > > RMs should ensure that the file is updated upon release. > > > > > > The badges are generated dynamically from Maven Central metadata, so > > > are whatever the image.shields.io website thinks is the latest. > > > > > > IMO these invisible dynamic queries go against the Privacy FAQ: > > > > > > https://privacy.apache.org/faq/committers.html > > > > > > I think it would be better to have a regular batch job to ensure the > > > status file is up to date and not rely on a 3rd party. > > > > > > > Sorry, I'm fairly lost here; I don't know what "image.shields.io" is. > > Nor when/how we started having those links/badges generated. > > > > I seem to remember that the RM had to update this file: > > > > https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties > > and the appropriate file in > > https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/ > > > > But then? Is there a script to run so that the site is updated? > > > > > > Gilles > > > > - > > 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: [rng] LGTM switch to CodeQL GH action
Hi. Le mer. 7 déc. 2022 à 14:11, Alex Herbert a écrit : > > The [rng] project was signed up to LGTM.com analysis (I presume at > their website). I don't recall that anything had been done on our part for the analyses of Commons repositories to appear on their web site. > This is now being decommissioned. The underlying > analysis engine is CodeQL and this is migrating to direct support as a > Github action. > > Do we want to continue with this for [rng]? There is a PR open by > their bot to enable it [1]. They were able provide a (nice) graphical interface without interfering with the repository. IMHO, this offer is thus a regression. Gilles > > AFAICR the analysis has never noticed any issues. We get far more > feedback from using the sonarcloud analysis that is run by the Jenkins > CI build [2]. > > I compared their recommended GH workflow to the one configured to > [lang]. It appears mostly the same. I note that both ask for write > permission to the security events. I do not know how this fits with > the security policy to not publicly disclose events until reviewed and > patched, i.e. I do not know if the security tab for the GH page is > restricted, and where event notifications will be sent. So I do not > want to enable this without further investigation, unless someone can > confirm what exactly the CodeQL build analysis will do if it finds > something. > > Alex > > [1] https://github.com/apache/commons-rng/pull/119 > [2] https://sonarcloud.io/project/overview?id=commons-rng > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
