Hi Gary, On Thu, 22 Feb 2024 at 17:14, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 totally agree. Maven optional dependencies provide, as far as I know, no value to the users of the artifact. Even the `requireUpperBoundDeps` Maven Enforcer rule seems to disregard those dependencies, i.e. if the version of an optional transitive dependency is higher than the version of a non-optional one, no error is reported. Same for `dependencyConvergence`. Also, according to my inquiries on the Jigsaw mailing list, the JPMS `require static` directive that makes a module optional should only be used for annotation-only modules (and IMHO for standard Java SE modules). For other kinds of modules the directive becomes problematic: a JPMS Commons Compress user not only needs to add `commons-codec` to its Maven dependencies, but also needs to add `org.apache.commons.codec` to its required modules. If he fails to do so the module will not be loaded even if it is available. Fortunately Commons Compress is well-engineered and easy to split. The code that depends on: * com.github.luben:zstd-jni, * org.brotli:dec, * org.ow2.asm:asm, * org.tukaani:xz. is already nicely separated in packages. IMHO those packages could be moved to separate artifacts **without** requiring a major version bump and connected to the rest of the code through a `CompressorStreamProvider` registered as `ServiceLoader` service. At least HotSpot loads all the additional JPMS modules that provide a required service. The rest of optional deps should in my opinion either be removed or made non-optional. Piotr PS: Splitting artifacts has also a beneficial effect on security alerts: if you don't use a certain dependency, you don't get a security alert when that dependency has a CVE. Unlike Maven, SBOMs usually also follow optional dependencies. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
