Hi all, I've previously been hesitant to add support for JPMS to our packages. My justification was that we would stay on Java 8 and we currently have split packages which would require a breaking change involving moving classes around. Well, first the reason doesn't hold since we've moved to a minimum of Java 17 and the second is less of a problem on 4.0 where we can accept breaking changes. So I'm going to propose what I feel is a reasonable design for JPMS support in 4.0. Keep in mind that the target will just be gremlin-driver users and embedded users that are building applications. This isn't for providers that create a standalone server as they benefit less from modularity.
These artifacts would get module descriptors: gremlin-language org.apache.tinkerpop.gremlin.language gremlin-shaded org.apache.tinkerpop.gremlin.shaded gremlin-core org.apache.tinkerpop.gremlin.core gremlin-util org.apache.tinkerpop.gremlin.util gql-gremlin org.apache.tinkerpop.gremlin.gql tinkergraph-gremlin org.apache.tinkerpop.gremlin.tinkergraph gremlin-driver org.apache.tinkerpop.gremlin.driver gremlin-annotations org.apache.tinkerpop.gremlin.annotations The rest stay classpath-only. gremlin-server, gremlin-groovy and gremlin-console are applications rather than libraries and rely on Groovy's dynamic class loading. hadoop-gremlin and spark-gremlin are both being deprecated. gremlin-test shares package names and isn't used by end users. The gremlin-driver "shaded" uber jar since JPMS users would use the regular jars. Gryo would not be supported on the module path, since Kryo needs deep reflection into JDK and TinkerPop internals. Users who need Gryo would use the classpath. A side note on gremlin-shaded, moditect-maven-plugin will be used to build it (needed to add a descriptor to gremlin-shaded after shading). Here are some changes required to make JPMS work: * No split packages. Classes that cause a package to be split across jars get renamed or moved. The affected packages are org.apache.tinkerpop.gremlin.language.grammar (gremlin-language and gremlin-core) and org.apache.tinkerpop.gremlin.util (gremlin-util and gremlin-core). We'd move the classes that are least used by users and keep the main entry points where they are. * Exports mirror today's public API. gremlin-core is a framework that providers extend, so it exports nearly everything. Only packages that are entirely internal are hidden, and no classes move just to hide them. * Stable dependencies. We avoid publishing module dependencies on libraries that have no stable module name. That means replacing javatuples with TinkerPop types, and replacing netty-all with the specific Netty modules we use. exp4j is another candidate for replacement. * Optional stays optional. TinkerGraph remains an optional dependency of the driver, discovered through a service rather than by class name. * Verified on the module path. The existing tests keep running on the classpath, and new example applications run on the module path as part of the build. Please let me know if you have any feedback. Thanks, Ken
