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