Update commons libs, Freemarker and JNA

[mbien]

• Update commons logging from 1.3.3 to 1.3.5
• Update commons lang3 from 3.14.0 to 3.17.0
• Update commons io from 2.16.1 to 2.18.0
• Update commons codec from 1.17.1 to 1.18.0
• Update commons compress from 1.26.2 to 1.27.1
• Update JSVG from 1.6.1 to 1.7.1 moved to Update JSVG from 1.6.1 to 1.7.1 #8412
• Update JNA from 5.14.0 to 5.17.0
• Update freemarker from 2.3.33 to 2.3.34

JSVG had a small code incompatibility which was addressed in the same commit

To prevent #7816 happening again, I checked the dependency trees for changes:

Details

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]

mvn eu.maveniverse.maven.plugins:toolbox:gav-tree -Dgav=org.apache.commons:commons-compress:1.27.1
[INFO] org.apache.commons:commons-compress:jar:1.27.1
[INFO] ├─com.github.luben:zstd-jni:jar:1.5.6-4 [compile, optional]
[INFO] ├─org.brotli:dec:jar:0.1.2 [compile, optional]
[INFO] ├─org.tukaani:xz:jar:1.10 [compile, optional]
[INFO] ├─commons-codec:commons-codec:jar:1.17.1 [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.16.0 [compile]

mvn eu.maveniverse.maven.plugins:toolbox:gav-tree -Dgav=commons-logging:commons-logging:1.3.3
[INFO] commons-logging:commons-logging:jar:1.3.3
[INFO] ├─avalon-framework:avalon-framework:jar:4.1.5 [compile, optional]
[INFO] ├─org.apache.logging.log4j:log4j-1.2-api:jar:2.23.1 [compile, optional]
[INFO] ├─org.apache.logging.log4j:log4j-api:jar:2.23.1 [compile, optional]
[INFO] ├─logkit:logkit:jar:2.0 [compile, optional]
[INFO] ╰─org.slf4j:slf4j-api:jar:2.0.13 [compile, optional]

mvn eu.maveniverse.maven.plugins:toolbox:gav-tree -Dgav=commons-logging:commons-logging:1.3.5
[INFO] commons-logging:commons-logging:jar:1.3.5
[INFO] ├─avalon-framework:avalon-framework:jar:4.1.5 [compile, optional]
[INFO] ├─org.apache.logging.log4j:log4j-1.2-api:jar:2.24.3 [compile, optional]
[INFO] ├─org.apache.logging.log4j:log4j-api:jar:2.24.3 [compile, optional]
[INFO] ├─logkit:logkit:jar:2.0 [compile, optional]
[INFO] ╰─org.slf4j:slf4j-api:jar:2.0.16 [compile, optional]

rest didn't have any dependencies

[mbien]

resolved a conflict and rebased

[matthiasblaesing]

Only eyeballed, but change makes mostly sense to me and seems to be done very thoroughly.

This does not hold true for the JSVG update. The commit message is wrong (update goes to 1.7.1, not 1.6.2). While it did not bump major version, it clearly broke API. Compare:

1.6.1:

https://github.com/weisJ/jsvg/blob/9c73862ee9ef6133a072e93162b766aec5fd4884/jsvg/src/main/java/com/github/weisj/jsvg/parser/ResourceLoader.java#L32-L37

1.7.1:

https://github.com/weisJ/jsvg/blob/e0ef0cd0e12ec7371c766b6ee4d22c74a527cb80/jsvg/src/main/java/com/github/weisj/jsvg/parser/ResourceLoader.java#L33-L37

Existing callers are broken by this.

[mbien]

thanks for spotting the copy/paste issue in the commit message. Will check the other messages too.

I noticed the API change and updated the (single) usage in the same commit as mentioned:

JSVG had a small code incompatibility which was addressed in the same commit

[matthiasblaesing]

I noticed the API change and updated the (single) usage in the same commit as mentioned:

JSVG had a small code incompatibility which was addressed in the same commit

We wrap the module, so this then should be come major version 2 with spec 2.0.0. At least that is my interpretation.

[mbien]

I don't think we took responsibility for fixing the versioning scheme of third party libs before. But i could be wrong and I also don't really care that much since it is just about a version String. But this would be extra work to add those checks for each wrapper update from now on.

[matthiasblaesing]

@mbien the problem is, that we decided to expose the module as API. I know, that we had such situations. The problem is, that I don't remember which library did this. Solution could be to remove the exported api and make this a module, that can be used as an implementation dependency. Then noone can rely on it.

@weisJ would it be possible, that JSVG in the future bumps major version when incompatible changes are introduced into the codebase?

[neilcsmith-net]

@mbien the problem is, that we decided to expose the module as API. I know, that we had such situations. The problem is, that I don't remember which library did this. Solution could be to remove the exported api and make this a module, that can be used as an implementation dependency. Then noone can rely on it.

I'm already relying on it! https://www.praxislive.org/blog/on-watch/ So, -1 to hiding it now. In fact, in general -1 to hiding third-party libraries - had enough problems with that with JNA years ago. Sometimes third-party libraries have different API rules than we do ourselves. I'm not sure if this is also related to weisJ/jsvg#119 somehow? Anyway, I say we live with it.

[mbien]

i will bump that spec version as suggested, want to fix something else first till i get to this pr

[matthiasblaesing]

I think it would make sense to split the update of JSVG off from this and do that in isolation.

[eirikbakke]

the problem is, that we decided to expose the module as API

Sorry, that was me! For my future reference, is there a way to do a "private" library wrapper module, used by only specific other modules?

[mbien]

removed the jsvg commit and rebased, will link the jsvg PR later from PR text

[weisJ]

I'm not sure if this is also related to weisJ/jsvg#119 somehow? Anyway, I say we live with it.

Yes this is very much related to the mentioned issue. In the current way the packages are structured it is almost impossible for me to keep full A(P/B)I compatibility with new releases. The next release will be focused on fixing this situation and provide a set of stable public facing APIs.

[matthiasblaesing]

Thank you.

[neilcsmith-net]

Sorry, that was me! For my future reference, is there a way to do a "private" library wrapper module, used by only specific other modules?

@eirikbakke good, don't apologize, that was the right approach! You can include wrapper libraries inside the utilising module, or expose the library packages via friend API to another module as you might with module code. Have a really good reason if you take either of those approaches. Hiding third-party APIs is generally not great. We should be OK with the fact that they do not necessarily follow the same versioning policies that we do in exposing them, and in documenting how people might use them.