Le 02/11/2024 à 13:19, Gilles Sadowski a écrit :
My question was and still is: Can modularization help?
Modularization is very much needed for Commons Compress, I think we
should at least split the compression part from the archive part, and
then further split by file format (commons-compression-* and
commons-archive-*).
This would greatly improve the situation with the optional dependencies.
Let's say I want to extract xz files, I would simply declare a
dependency on commons-compression-xz in my pom.xml, which would pull the
org.tukaani:xz dependency transitively, instead of having to declare two
dependencies on commons-compress and org.tukaani:xz.
Unfortunately modularization will hardly help with the dependencies on
commons-codec, commons-lang and commons-io, because as of
commons-compress 1.26 they are used almost everywhere in the code. Only
commons-codec is restricted to a couple of formats (LZ4 and Snappy), but
commons-io is now part of the core *public* API [1], which is really bad
because we can no longer remove the dependency without breaking the
binary compatibility (and I think we should do it as soon as possible
before this new public method gets widely used).
Emmanuel Bourg
[1]
https://github.com/apache/commons-compress/blob/863be804/src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java#L224
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
