Hi Vladimir:
On 8.10.2025 12:08, Vladimir Sitnikov wrote: > Direction (high level): > * commons-compress-core (shared utils; JDK GZip/Deflate) > * commons-compress-tar, …-zip, …-7z, …-cpio, …-ar, etc. > * Optional codec modules for external deps (…-xz, …-zstd, …-brotli) > * commons-compress meta POM that brings today’s full set > * Preserve existing APIs; ArchiveStreamFactory remains (clear error if a > requested format isn’t on the classpath) This looks good to me. However, such a split can only be done in version 2.x, which will use the `o.a.c.compress2` package. We cannot apply it to version 1.x for the reasons Elliotte mentioned: users could end up with an older `commons-compress` alongside `commons- compress-tar`, both containing the same package. See apache/commons- compress#490 [1] for details. For Commons Compress 2.x, I would suggest going a step further: - Introduce a dedicated `commons-compress2-api` module containing `ArchiveStreamFactory`, `CompressStreamFactory`, relevant exceptions, and as few additional classes as possible. Once modules are split, mismatched versions are inevitable; an almost “pure API” module would help reduce incompatibilities between `commons-compress2-api` 2.0.0 and other more recent `2.x` modules [3]. - Limit the “capabilities” required by each module. There is an interesting Alpha-Omega project called CapsLock, which tracks privileged calls (file, network, reflection, native libs, process execution) to mitigate supply chain attacks. Commons Compress is currently flagged by CapsLock as relying on many privileges. Since compression should ideally be a pure data-processing step, we could aim to drop most of these in 2.x. For example, starting with 1.29.0, we already rely on Commons IO for most file access operations. Best, Piotr [1] https://github.com/apache/commons-compress/pull/490 [2] https://github.com/apache/commons-compress/pull/673 [3] Limits, not eliminates. Of course `commons-compress-foo` will depend on `commons-compress-api`, so introducing new custom types into API method signatures will still cause linkage errors. [4] https://alpha-omega.dev/blog/crustabilities-capabilities-rust-and-capslock/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
