Le lun. 4 nov. 2024 à 09:27, Emmanuel Bourg <ebo...@apache.org> a écrit : > > 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 >
Is it "bad" because "Commons IO" is too heavy as a dependency, or because the "IOIterator" functionality is not actually used (and a plain "Iterator" would suffice)? If it's the former, then the solution may again be to modularize "Commons IO". Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
