ArcadeData
Use Java Modules instead of fatjar/maven shade plugin
I don't think that the fatjar/shaded maven plugin change introduced in 21.12.1 is a good thing for this project.
https://github.com/ArcadeData/arcadedb/pull/162
I think the default should be to use java modules (using META-INF/versions/* if you need to support java8 and 9+ in the same jar) but only shade (truly shade - not just include) external dependencies when absolutely necessary).
The current strategy has broken all of my uses of arcade. I typically create modules out of projects that haven't adapted a module strategy. This usually entails simply adding "Automatic-Module-Name: {some module name}" in the manifest of the jar. Sometimes projects cause split packages (when a java package exists in two jars - not allowed with java modules). In those cases, I either filter out the split package (when they include some files from a different package or module for convenience...) or merge jars together (when the same project has 2 or more jars with the same package). This tends to work but is a bit of a burden with dependency and build management.
With arcadedb and formerly orientdb, there was an attempt to create modules but that never fully worked (maybe it did with just the db and dependencies) in a larger project that required embedding the db. Using the methods above I could work around this. However, with the fatjar, this has become untenable.
Please consider using java modules as the default to cover both 8 and 9+. It that's not possible, then consider having a separate build for java lower than 9.
PS fatjars are convenient but consider the log4j2 type issue that occurred recently. If the dependency is embedded, it becomes more difficult to identify and more difficult to address.
The main reason is #157
We would like to load "plugins", such as mongo, redis and gremlin, on separate classloaders.
The idea is to load specific interfaces using the ServiceLoader: ServerPlugin and Importer/Exporter
Java modules have not this scope/purpose
One reason is to not pollute the classpath and reduce the risk that two plugins depend on the same library with different versions: this event could create problems at runtime
ArcadeDb main modules will remain plain jar as they are right now and we can also use java module to define which parts will be exported, but we have not discussed it yet
About Java 8 support, sincerely in my opinion we should move forward to java 17.
To get the newer versions working, I did the following:
Removed the shaded plugin from com.arcadedb:arcadedb-gremlin and rebuilt 22.1.2 so that it wouldn't make a fat jar. Made modules out of:
com.arcadedb:arcadedb-engine com.arcadedb:arcadedb-gremlin org.opencypher: org.apache.tinkerpop:gremlin-core org.apache.tinkerpop:gremlin-groovy commons-configuration:commons-configuration commons-collections:commons-collections commons-logging:commons-logging org.slf4j:slf4j-api org.javatuples:javatuples
I think these were all done simply by adding Automatic-Module-Name (with a value that matches the respective jar) to the manifest of each.
Then my app uses modules and everything worked.
I'm not sure what the issue is that you are referring to... shading jars and changing their package names is what is usually done to prevent jar version differences for jars that you don't control. But I only see shading in place without package renaming to create a fatjar.