arcadedb-gremlin 26.8.1 is unusable standalone: arcadedb-network is not declared, only reachable through a 'provided' dependency

[ruispereira]

Summary

A project that depends only on com.arcadedb:arcadedb-gremlin:26.8.1 fails at runtime on the first Gremlin query with:

java.lang.NoClassDefFoundError: com/arcadedb/remote/RemoteDatabase

RemoteDatabase lives in arcadedb-network, which the published POM never declares. The only path to it is arcadedb-server, declared with scope=provided — which is not transitive, so consumers never receive it.

Version: 26.8.1.

Reproducer

pom.xml, one dependency:

<dependencies>
  <dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-gremlin</artifactId>
    <version>26.8.1</version>
  </dependency>
</dependencies>

final Path dir = Files.createTempDirectory("g");
try (final DatabaseFactory f = new DatabaseFactory(dir.resolve("db").toString());
     final Database db = f.create()) {
  db.getSchema().createVertexType("V");
  db.getQueryEngine("gremlin").analyze("g.V()");   // NoClassDefFoundError
}

Resolving that POM:

artifact	on the resolved classpath
arcadedb-engine	yes (via arcadedb-integration)
arcadedb-network	no

Adding arcadedb-network by hand makes the same program run.

Why it resolves this way

From the published arcadedb-gremlin-26.8.1.pom:

com.arcadedb:arcadedb-server        scope=provided
com.arcadedb:arcadedb-server        scope=test
com.arcadedb:arcadedb-integration   scope=compile

arcadedb-network is not declared at all. The module compiles because arcadedb-server (provided) brings it in at compile time; provided is then dropped for consumers, and nothing else supplies it.

Why it is hit immediately

The class is referenced on the ordinary query path, not in some remote-only corner:

// gremlin/src/main/java/com/arcadedb/gremlin/ArcadeGremlin.java:71
if (graph.database instanceof RemoteDatabase)

An instanceof against a missing class fails when the enclosing method is linked, so even a purely embedded user who never touches remote functionality trips over it. ArcadeGraph and ArcadeGraphFactory import it too.

Suggested fix

Declare the dependency the module actually uses, at compile scope:

<dependency>
  <groupId>com.arcadedb</groupId>
  <artifactId>arcadedb-network</artifactId>
  <version>${project.version}</version>
</dependency>

Relying on a provided dependency for a compile-time reference works in the reactor and silently breaks for every downstream consumer, since the reactor build never resolves the module the way Maven Central serves it.

Worth checking the sibling wrappers (graphql, mongodbw, redisw, postgresw, bolt) for the same pattern, and adding a smoke test that resolves each published artifact on its own and runs one query — that is the only shape of test that catches this class of problem, since it cannot reproduce inside the multi-module build.

Secondary

With the classpath completed, the same run prints:

ANTLR Tool version 4.9.1 used for code generation does not match the current runtime version 4.13.2
ANTLR Runtime version 4.9.1 used for parser compilation does not match the current runtime version 4.13.2

TinkerPop's generated parser was built against ANTLR 4.9.1 while 4.13.2 is what resolves. It is a warning rather than a failure here, but the pairing is worth pinning deliberately rather than inheriting.

[ruispereira]

I checked the sibling modules I suggested, so you don't have to. All seven share the POM shape (arcadedb-network undeclared, arcadedb-server at provided), but only gremlin is actually broken by it:

module	uses com.arcadedb.remote.*	uses com.arcadedb.server.*
gremlin	3 files	7 files
graphql	–	–
mongodbw	–	2 files
redisw	–	4 files
postgresw	–	3 files
bolt	–	4 files
grpcw	–	11 files

graphql touches neither, so it resolves and runs standalone: I fuzzed it through analyze() on a classpath built from its POM alone, with no arcadedb-network present, and it worked.

The five protocol wrappers reference only com.arcadedb.server.*. They are server plugins loaded inside a running server, which supplies those classes, so provided is the right scope there and there is nothing to fix.

That leaves gremlin as the one case, because it is the only module that is both usable as an embedded library and dependent on a provided-only artifact from its ordinary query path.