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
>> >
>>
>
