Before splitting maybe review why there are deps, don't think any is really needed and it was mainly pre java 8 time.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 22 févr. 2024 à 17:29, Xeno Amess <xenoam...@gmail.com> a écrit : > Another reason for suggesting common-compress split to several sub-modules: > I see no application, nor lib, nor software that use common-compress and > use all of the algorithms supported by common-compress... > Usually we just use one or two algorithms we actually need... > so splitting into several submodules (and letting users pick what they > need) seems reasonable... > If an all-in-one entry is really needed, we still have the SPI solution. > > Xeno Amess <xenoam...@gmail.com> 于2024年2月23日周五 00:23写道： > > > > 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 love this... just like what done in vfs right?. > > > > Gary Gregory <garydgreg...@gmail.com> 于2024年2月23日周五 00:14写道： > > > >> A basic issue is that there is a disconnect between Maven dependency > >> declarations in a POM and running applications outside of Maven aware > >> environment ('mvn' and IDEs). When you write your app, you deliver jars, > >> you start the JVM, and so on, and if you don't follow Maven dependencies > >> you can run into issues like missing classes. Maven, within a module, > has > >> no way to say "if you use this feature, then you need that jar". > >> > >> 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. > >> > >> The KISS solution here IMO is to remove the POM optional attribute from > >> these dependencies. Apps can always prune dependency if they wish to do > >> so. > >> > >> Gary > >> > >> On Thu, Feb 22, 2024, 4:08 AM Andrew Coates <big.andy.coa...@gmail.com> > >> wrote: > >> > >> > Hi all, > >> > > >> > I'm seeing a runtime failure using TarArchiveOutputStream when > updating > >> to > >> > commons-compress 1.26.0. > >> > > >> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets > >> > at org.apache.commons.compress@1.26.0 > >> > > >> > > >> > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.<init>(TarArchiveOutputStream.java:212) > >> > at org.apache.commons.compress@1.26.0 > >> > > >> > > >> > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.<init>(TarArchiveOutputStream.java:157) > >> > at org.apache.commons.compress@1.26.0 > >> > > >> > > >> > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.<init>(TarArchiveOutputStream.java:147) > >> > at testcontainers@1.19.5 > >> > > >> > > >> > /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350) > >> > ... > >> > > >> > Commons-compress 1.26.0 contains changes to make use of commons-codec, > >> > rather than its own copy of files, but I see that the POM marks > >> > commons-codec as *optional*. Excuse my potential ignorance, but I > >> thought > >> > optional dependencies shouldn't cause runtime failures if not present. > >> Is > >> > this not the case? > >> > > >> > Obviously, I can just add commons-codec as an explicit dependency. But > >> this > >> > seems wrong IMHO. > >> > > >> > Should I sign up for an account and raise this as a bug in Jira? > >> > > >> > Thanks, > >> > > >> > Andy > >> > > >> > > >
