Re: [VOTE] Release Apache Commons Logging 1.3.2 based on RC2
Hi Gary, On Sat, 11 May 2024 at 19:55, Gary Gregory wrote: > Details of changes since 1.3.1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.2-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.2-RC2/site/changes-report.html The `RELEASE-NOTES.txt` file contains the changes for 1.3.1 twice and does not contain the changes for 1.3.2. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] GitHub is done with Java 8
Hi Gary, On Mon, 29 Apr 2024 at 13:58, Gary Gregory wrote: > To resolve this issue in the least disruptive manner, I updated builds > that need Java 8 AND macOS from "macos-lateset" to "macos-13". In Log4j I updated all builds that require Java 8 + another JDK to use `zulu` as distribution if `runner.os == 'macOS'`. Another solution that might work is to use `x64` as architecture for `macos-latest`, but the runners we be slower and might throw an OOM. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is there a blog for commons?
Hi Bruno, On Fri, 19 Apr 2024 at 13:30, Bruno Kinoshita wrote: > Maybe an option would be to just have it under > https://commons.apache.org/blog/, as part of the project website in Git, > published with the site manually/ASF CRM/etc? I think that way INFRA would > not have to be involved? The Logging Services blog[1] uses Jekyll under the hood. This is already supported by INFRA through an `.asf.yaml` configuration option[2]. Piotr [1] https://logging.apache.org/blog/ [2] https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#jekyll_cms - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Logging 1.4.0 based on RC1
Hi Gary, On Sun, 17 Mar 2024 at 13:45, Gary Gregory wrote: > For example? The Logback PR requires Java 11. What else? Logkit? Maybe but > I've never heard anyone ask for that. The two OSGi PRs are important: * https://github.com/apache/commons-logging/pull/188: fixes a typo in the OSGi descriptor that prevented OSGi frameworks to correctly find SLF4J, * https://github.com/apache/commons-logging/pull/191: allows the `ServletContextCleaner` to be used with modern servlet containers in OSGi. Piotr PS: Why did you choose 1.4.0 as version instead of 1.3.1, since the release contains only bug fixes? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi sebb, On Thu, 29 Feb 2024 at 10:25, sebb wrote: > > but dependency management can be used to > > prevent version mismatches. > > What dependency management is that? Does Maven manage this? > Seems like users would be forced to use extra controls to ensure only > comaptible combinations of artifacts were used. Maven users would be forced to add a new `commons-compress-bom` artifact (in my PR) to their dependency management. As far as I know other build systems (Gradle, Coursier, probably Apache Ivy) resolve version conflicts with a "highest version wins strategy", so the change will be a no-op for them. Yes, this change might require a developer to supervise the upgrade, so it might require a major version bump to drive their attention. However personally I find it less problematic than having half the dependency stack using `o.a.c.compress` and half of it using `o.a.c.compress2`. The necessity to align the versions of a multi-module project is something many users are aware of (and the others use Spring Boot dependency management ;-) ). Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi sebb, On Wed, 28 Feb 2024 at 23:48, sebb wrote: > > Remark that I am talking about moving whole packages to new artifacts. > > Will these packages be renamed? > > If not, then I don't see how you can prevent possible class duplication. Do they need to be renamed? This breaks backward compatibility. A user could have duplicated classes if he has an old `commons-compress` 1.26.0 together with a newer `commons-compress-core`, but dependency management can be used to prevent version mismatches. Since an example is better than a thousand words I submitted a PoC on how to split Commons Compress: https://github.com/apache/commons-compress/pull/490 A simple `mvn clean verify` succeeds. I just need to smoothen out the CI's failures. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi Romain, On Wed, 28 Feb 2024 at 16:30, Romain Manni-Bucau wrote: > > Hmm, splitting will require a package change at least for osgi. OSGi should be painless: the common practice is to use `Import-Package` instead of `Require-Bundle`, this way it is up to the OSGi environment to figure out that a certain package is in `commons-compress-core` instead of `commons-compress`. Remark that I am talking about moving whole packages to new artifacts. If we were to split a package in two parts, I agree with the previous posts that a new major version, Maven coordinates and package names are required. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi Elliotte, On Wed, 28 Feb 2024 at 13:44, Elliotte Rusty Harold wrote: > I'm not quite sure what you're proposing. This works if you also > change the package to something like org.apache.commons.compress2. It > does not work without changing the package names. The bottom line is: > > 1. A classpath MUST NOT have the same fully package qualified name in > more than one JAR. This is a hard requirement in Java 9+ with JPMS. > The JVM will not run a program that violates this. It is a very > important requirement in Java 8. > > 2. Maven and Gradle cannot resolve dependency conflicts between jars > with different groupID:artifactID. They both treat them as fully > independent artifacts, even if they're not, and will add both to a > classpath, thereby violating rule #1. Currently Commons Compress 1.26.0 has: * a single `commons-compress` artifact with packages: o.a.c.c.compressors, o.a.c.c.compressors.brotli, etc. What I am proposing is for 1.27.0 to have: * an (almost) empty `commons-compress` artifact that depends on `commons-compress-core`, `commons-compress-brotli`, etc. This artifact should only have a JPMS module descriptor with `requires transitive` directives. * a `commons-compress-brotli` artifact that depends on `org.brotli:dec` and a single package: o.a.c.c.compressors.brotli, * a `commons-compress-core` artifact with packages o.a.c.c.compressors, etc. JPMS does not really care which module has which package. As long as they are disjoint it will be fine. Also, since `commons-compress` will have `requires transitive` directives, libraries compiled against 1.26.0 that use `requires o.a.c.compress;` will still be able to read the `o.a.c.compress.core` module. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi Elliotte, On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold wrote: > > On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz > wrote: > e will not be loaded even if it is available. > > > > Fortunately Commons Compress is well-engineered and easy to split. The > > code that depends on: > > > > * com.github.luben:zstd-jni, > > * org.brotli:dec, > > * org.ow2.asm:asm, > > * org.tukaani:xz. > > > > is already nicely separated in packages. IMHO those packages could be > > moved to separate artifacts **without** requiring a major version bump > > I wish. It's not that commons-compress is badly factored. It's that > Maven and Java don't really allow for compatible upgrades that split > existing artifacts into new artifacts. This causes big, hard-to-debug > runtime failures. The problem is bad in Java 8 and earlier. It got > much worse in Java 9+ with JPMS. > > The only compatible path that splits artifacts is to rename both the > Maven coordinates AND the packages. Otherwise there will be multiple > copies of the same class in the classpath, and either the wrong one > will be chosen some of the time causing hard to debug runtime failures > or (with JPMS) the JVM will simply refuse to run the program at all. Changing Maven coordinates is in my opinion not a good solution in this case. It causes the existence of dependency stacks that feature HTTP client 3.x through 5.x and users are not eager to choose a single version. What about creating: * separate `commons-compress-zstd`, `commons-compress-brotli`, `commons-compress-pack200`, `commons-compress-xz` artifacts with the packages that require external dependencies, * a new `commons-compress-core` (or `-api` and `-impl`) with the rest of the code, * an empty `commons-compress` artifact with a hard dependency on the remaining ones. It just needs a JPMS module descriptor with `requires transitive` directives to the other modules. This way won't have problems when they automatically upgrade `commons-compress`. They'll just end up with many additional dependencies. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Hi Gary, On Thu, 22 Feb 2024 at 17:14, Gary Gregory wrote: > What I've been going in some projects is to never use Maven optional > dependencies and split Maven projects into multi-module ones and never use > optional dependencies when I care about what depends on what. I totally agree. Maven optional dependencies provide, as far as I know, no value to the users of the artifact. Even the `requireUpperBoundDeps` Maven Enforcer rule seems to disregard those dependencies, i.e. if the version of an optional transitive dependency is higher than the version of a non-optional one, no error is reported. Same for `dependencyConvergence`. Also, according to my inquiries on the Jigsaw mailing list, the JPMS `require static` directive that makes a module optional should only be used for annotation-only modules (and IMHO for standard Java SE modules). For other kinds of modules the directive becomes problematic: a JPMS Commons Compress user not only needs to add `commons-codec` to its Maven dependencies, but also needs to add `org.apache.commons.codec` to its required modules. If he fails to do so the module will not be loaded even if it is available. Fortunately Commons Compress is well-engineered and easy to split. The code that depends on: * com.github.luben:zstd-jni, * org.brotli:dec, * org.ow2.asm:asm, * org.tukaani:xz. is already nicely separated in packages. IMHO those packages could be moved to separate artifacts **without** requiring a major version bump and connected to the rest of the code through a `CompressorStreamProvider` registered as `ServiceLoader` service. At least HotSpot loads all the additional JPMS modules that provide a required service. The rest of optional deps should in my opinion either be removed or made non-optional. Piotr PS: Splitting artifacts has also a beneficial effect on security alerts: if you don't use a certain dependency, you don't get a security alert when that dependency has a CVE. Unlike Maven, SBOMs usually also follow optional dependencies. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
Hi Gary, On Sat, 10 Feb 2024 at 17:26, Gary Gregory wrote: > The package would change from org.apache.commons.logging to > org.apache.commons.logging2. > The Maven coordinates would change from > commons-logging:commons-logging to org.apache.commons:commons-logging2 The only case in which such a change would be useful is if all the logging API maintainers can sit down around a table and decide to adopt `org.apache.commons.logging2.L ogger` as the common denominator of their APIs. Currently logging faces new challenges that could be solved with a new (minimal) API, such as: * tracing should be an integral part of the API, * thread-bound contexts are problematic, so there should be an easy way to retrieve context data from the processing flux (Spring Reactor Flow, Akka Actor, etc) and not the current thread. If such a thing is even possible, it would be nice if we can get `jakarta.logging` as the package prefix. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
Hi Gary, On Sat, 10 Feb 2024 at 17:26, Gary Gregory wrote: > My main driver for the next version is to drop support and dependency > on the Log4j 1.x JARs file(s). I speak of JAR files here as opposed to > APIs, see below. Log4JLogger is disabled by default in version 1.3.0 (cf. [1]) and the dependency on `log4j:log4j` is optional, so it is a compile-only dependency. If any security expert complains that there is a mention of `log4j:log4j:1.2.17` in the POM file, I would suggest changing security expert. ;-) > I see several ways to drop Log4j 1.x JARs. > 1) Replace the dependency on Log4j 1.x with the Log4j 2 compatibility > JAR for 1.2: org.apache.logging.log4j:log4j-1.2-api > This maintains BC and can become 1.4.0. It shouldn't really matter what JAR we use to compile Commons Logging. People will still use `log4j/reload4j` at runtime. > 2) A re-implementation of Log4JLogger where all methods call Log4j 2 APIs. > This maintains BC and can become 1.4.0. > It looks like this is not possible in a straightforward manner > because we have Log4j 1 classes in the public API, specifically > org.apache.commons.logging.impl.Log4JLogger.Log4JLogger(Logger). It > might not be worth hacking around that if that's even possible. The dependency on `log4j-api` is also optional, so this will break user projects. If users are willing to upgrade to a more modern logging backend than Log4j 1.x, they can do it right now. Release 1.3.0 binds to Log4j API as first choice (followed by SLF4J and JUL), so we already short circuited many logging configurations that were using: 1. commons-logging -> log4j-over-slf4j -> slf4j-api, 2. commons-logging -> log4j-1.2-api -> log4j-api. > 3) A hard delete of org.apache.commons.logging.impl.Log4JLogger (the > class is deprecated in 1.3.0 FWIW). > This breaks BC and requires a 2.0.0 with a package name and Maven > coordinate change. > The package would change from org.apache.commons.logging to > org.apache.commons.logging2. > The Maven coordinates would change from > commons-logging:commons-logging to org.apache.commons:commons-logging2 +1 on removing the class. This seems the only solution, where we make a stand against using 20 years old logging frameworks. Users will still be able to use Log4j 1.x/Reload4J through the `slf4j-reload4j` bridge that Ceki still maintains. I wouldn't change the Maven coordinates/Java package though: Apache Commons Logging is a very primitive interface compared to the alternatives. I doubt anybody will recompile against the new package and legacy libraries will still be stuck at 1.3.0. If a user has to make changes in his code, he might as well migrate to Log4j API (which is a superset of JCL) or SLF4J (which does not allow to log objects, but is mostly "source compatible"). There are automatic recipes for both migrations[2]. > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. I wouldn't do that. Technically this is not a breaking change, but in practice it breaks user applications. Piotr [1] https://github.com/apache/commons-logging/blob/809f22417beeda262a631362d160ffbbfa34309d/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java#L142-L153 [2] https://docs.openrewrite.org/recipes/java/logging - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi Hervé, On Fri, 5 Jan 2024 at 08:14, Herve Boutemy wrote: > Piotr found the issue about the second run of bundle plugin and about > moditect 1.1.0 sensitivity to TZ: I don't know how hard it was to learn this, > nor how. > Do you have any idea on how to ease such discovery? The first time we encountered a difference in a zipfile metadata, it was hard. We knew from the binary diff from diffoscope that the difference is in the metadata, but it took us some time to notice that the file listings differed by an executable flag. For the Moditect problem I already knew where to look and I noticed that the timestamps from Gary's official artifacts and mine differed by 6 hours. Since the UNIX `unzip` utility does not support the "Extended Timestamp" I used Commons Compress to list all the extensions in the ZIP entries. In general I think that diffoscope could be improved by: * listing all the extensions of ZIP entries explicitly and in order, * adding some basic properties for each file, e.g. "Java class file, bytecode 52" or "Text file, CRLF line endings". Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi Gary, On Fri, 29 Dec 2023 at 15:11, Gary Gregory wrote: > I run, copied from the > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/commons/compress/commons-compress-1.25.0.buildspec: > > mvn -Prelease clean package package -DskipTests -Dmaven.javadoc.skip > -Dgpg.skip -Dcyclonedx.skip -Dcommons.release.dryRun > -Dcommons.release.isDistModule=false > > Then: > > mvn package package artifact:compare Maven has a short guide to check reproducibility: https://maven.apache.org/guides/mini/guide-reproducible-builds.html If you want to check a local artifact vs a previous local artifact you need to use: mvn clean install mvn clean package artifact:compare -DskipTests The first run install the artifact into the local Maven repo, the second one generates new ones and compares them with those installed. To check local vs remote you just need the second part. I am able to reproduce the current Commons Compress snapshot with: export TZ=UTC export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 mvn clean package artifact:compare \ -Dreference.repo=apache.snapshots \ -DskipTests \ -Dcommons.spdx.version=0.7.1 -Dspdx.skip I have no idea how those snapshots are generated, but they match my local ones. The last line bumps the SPDX Maven Plugin to a version that supports `-Dspdx.skip` ;-) Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi Gary, On Fri, 29 Dec 2023 at 13:37, Gary Gregory wrote: > I do appreciate the fact that I can ask "Am I reproducible" but the > output is... cryptic. Yes, unfortunately if the check fails, finding the reason of the failure is hard. > For example: > ... > ├── META-INF/MANIFEST.MF > │ @@ -65,11 +65,12 @@ > │ b.asm;resolution:=optional,javax.crypto;resolution:=optional,javax.cryp > │ to.spec;resolution:=optional,org.apache.commons.codec.digest,org.apache > │ .commons.io,org.apache.commons.io.file.attribute,org.apache.commons.io. > │ input,org.apache.commons.io.output,org.apache.commons.commons-codec;res > │ olution:=optional,org.apache.commons.commons-io;resolution:=optional > │ Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N > │ OTICE.txt > │ +Originally-Created-By: Apache Maven Bundle Plugin 5.1.9 > │ Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > │ Tool: Bnd-6.4.1.202306080939 > │ Multi-Release: true You have a difference in the MANIFEST.MF that consists of an additional "Originally-Created-By" header. Hervé already solved this mystery and you can find the Maven command line required here: https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/commons/compress/commons-compress-1.25.0.buildspec The reproducibility problem is caused by multiple executions of the Apache Maven Bundle Plugin. If you start with an empty `target` directory: * the first execution creates a MANIFEST.MF file, notably a "Created-By" header, * the second execution reads the MANIFEST.MF file, changes it and renames the "Created-By" header from the first execution into "Originally-Created-By". TL;DR: Running `mvn package package artifact:compare` solves the problem. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi Gary, On Thu, 28 Dec 2023 at 16:03, Gary Gregory wrote: > What value for $NEXUS_REPO would one use to verify repro _after_ a > release? I want to experiment with Apache Commons components... The `reference.repo` system variable is used by the `referenceRepo` parameter of `artifact:compare`: https://maven.apache.org/plugins/maven-artifact-plugin/compare-mojo.html with a default value of `central`, so you can skip setting the parameter. I can reproduce most of the artifacts in your latest Commons Fileupload release with this incantation: export TZ=UTC export JAVA_HOME=...path to JDK 17... mvn package artifact:compare \ -DskipTests \ -Dcyclonedx.skip \ -Dcommons.spdx.version=0.7.1 -Dspdx.skip The Maven Artifact Plugin only compares those artifacts, which are attached to the current build, so skipping CycloneDX and SPDX generation effectively prevents performing a reproducibility check on those artifacts. This is not ideal, but: * SPDX has a lot of reproducibility problems, * CycloneDX is usually reproducible, but I am probably affected by issue#410 [2], * we actually only care about the binary artifacts and POMs, the rest is a bonus. Piotr [1] https://github.com/jvm-repo-rebuild/reproducible-central [2] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/410 PS: We are mixing threads from multiple lists. For those following dev@commons, NEXUS_REPO is a reference to this thread from dev@logging: https://lists.apache.org/thread/163ow0knp5q29hrsh1doqm3jwxkrzwoo - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deploying SNAPSHOTS from GH workflows
Hi Gary, On Wed, 20 Dec 2023 at 14:57, Gary Gregory wrote: > > Also FYI, over at Log4j, we (Volkan and Piotr are the drivers) have been > creating releases from GitHub. I'm not sure we need to go this far here, > but there might be tidbits there that may prove useful. Thanks for mentioning it. I think we could put all our scripts together and create something better without reinventing the wheel in each project. For example: * We all receive Dependabot PRs. Volkan did a tremendous amount of work to find a way to merge them automatically (there are GHA permissions everywhere that make it a complex operation, especially if we want to keep the Github token's permissions to a minimum). Commons could reuse that. * At Log4j we use a Beanshell script to create bin and src archives. Personally I find the results acceptable, but somehow lacking (e.g. it fails in Git worktrees). For this task the `commons-release-plugin` together with the `maven-assembly-plugin` and a list of files from the `maven-scm-plugin` could be a better choice. * If we were to start publishing VEX files, a common Github Actions bot could help inter-project coordination. For example if a `commons-compress` dependency publishes a CVE (let's say `snappy-java` to make it real), the bot could open an issue in `commons-compress`. After the Commons team analyses the issue with a justification, the bot could open an issue with `log4j-core` (which uses `commons-compress`) and attach the analysis performed by the Commons team, thus greatly simplifying the process. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi all, On Mon, 27 Nov 2023 at 00:15, Piotr P. Karwasz wrote: > 2. For some strange reason I had to set `TZ=America/New_York` to make > the main JAR reproducible. Either the Moditect or the Maven JAR plugin > are responsible for that. The recent Commons artifacts are hard to reproduce, since one of the environment variables required by reproducibility is the timezone of the system that generated the artifacts. The problem is due to the Moditect plugin issue#222. Until this problem is resolved, could you provide you timezone in the vote e-mails? Piotr [1] https://github.com/moditect/moditect/issues/222 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Validator 1.8.0 based on RC1
Hi Elliotte, On Sun, 3 Dec 2023 at 14:13, Elliotte Rusty Harold wrote: > > https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-390 > and https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-357 > are both open dependency upgrades with security implications. If > they've already been fixed, then please close the issues. > > If they haven't been fixed, I vote -1 until they are. Looking at head, > I think VALIDATOR-357 has been fixed and should be closed, but > VALIDATOR-390 is still open. Looking at the SBOM, the only dependencies (including transitive ones) are: * commons-beanutils 1.9.4, * commons-digester 2.1, * commons-logging 1.3.0, * commons-collections 3.3.2. None of them have CVEs. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1
Hi Gary, > 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... I performed the following tests: * I tested the signature and hashes of the ZIP archives, * I tested the source archive and the reproducibility of binaries with: mvn clean verify artifact:compare -Dreference.repo=https://repository.apache.org/content/repositories/orgapachecommons-1676 * I tested 4 simple JLink runtimes: JCL + Log4j Core 2.x, JCL + Log4j Core 3.x, JCL + `java.logging` and just JCL. +1 (non binding): everything works correctly with the following remarks: 1. the SPDX artifact is not reproducible, 2. For some strange reason I had to set `TZ=America/New_York` to make the main JAR reproducible. Either the Moditect or the Maven JAR plugin are responsible for that. 3. The SHA512 sums in the distribution can not be used with `sha512sum -c` (they lack the file name). Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
