commons-compress dependecy on commons-codec and commons-lang3 was missing

[matthiasblaesing]

Closes: #7814

[mbien]

makes sense, commons-compress seems to have three non-optional compile time dependencies: codec, io and lang3

$ mvn eu.maveniverse.maven.plugins:toolbox:gav-tree -Dgav=org.apache.commons:commons-compress:1.26.2
[INFO] org.apache.commons:commons-compress:jar:1.26.2
[INFO] ├─com.github.luben:zstd-jni:jar:1.5.6-3 [compile, optional]
[INFO] ├─org.brotli:dec:jar:0.1.2 [compile, optional]
[INFO] ├─org.tukaani:xz:jar:1.9 [compile, optional]
[INFO] ├─commons-codec:commons-codec:jar:1.17.0 [compile]
[INFO] ├─org.ow2.asm:asm:jar:9.7 [compile, optional]
[INFO] ├─commons-io:commons-io:jar:2.16.1 [compile]
[INFO] ╰─org.apache.commons:commons-lang3:jar:3.14.0 [compile]

[matthiasblaesing]

@mbien yeah, I had a look at the module-info.class ;-). Thanks.

[neilcsmith-net]

Yes, commons-lang3 and commons-io came in with 1.26.0, and commons-codec became non-optional in 1.26.1 AFAIK. This should have been picked up in #7237 We had some minor release issues with NBPackage with merge of apache/netbeans-nbpackage#49 too. At least there the transitive dependencies are brought in. For NetBeans we could really do with making sure we find a way to highlight dependency updates in libs. @mbien how "easy" to do a diff of transitive dependencies as part of https://github.com/apache/netbeans/blob/master/.github/scripts/BinariesListUpdates.java ?

[mbien]

well, right now it runs in java and simply uses the maven central search to query versions. To get the dependency tree, this would have to use more external libs which would also require to resolve every single dependency (might be very slow and potentially be throttled by the service).

Not sure how I would do this, potentially even in bash + maven toolbox, otherwise this might end up being a larger program and no longer a "script".

Also: I am not sure if anyone outside of me is actually using this. I also asked myself the question while toying with #6630

[mbien]

btw the very first version of this (which I never committed), generated a gigantic pom and ran the version check plugin on it -> this might be also an approach to take since this could run more plugins.