arcadedb-engine
Used in:
components
- OverviewOverview
- VersionsVersions
- DependentsDependents
- DependenciesDependencies
<dependency>
<groupId>com.arcadedb</groupId>
<artifactId>arcadedb-engine</artifactId>
<version>26.9.1</version>
</dependency><?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright © 2021-present Arcade Data Ltd (info@arcadedata.com)
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
SPDX-FileCopyrightText: 2021-present Arcade Data Ltd (info@arcadedata.com)
SPDX-License-Identifier: Apache-2.0
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.arcadedb</groupId>
<artifactId>arcadedb-parent</artifactId>
<version>26.9.1</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>arcadedb-engine</artifactId>
<packaging>jar</packaging>
<name>ArcadeDB Engine</name>
<properties>
<disruptor.version>1.2.21</disruptor.version>
<gson.version>2.14.0</gson.version>
<lz4-java.version>1.11.2</lz4-java.version>
<lucene.version>10.5.1</lucene.version>
<!--
ONE GraalVM version, everywhere. This property, native/pom.xml's
native.graalvm.version and native-image.yml's setup-graalvm java-version are all
25.0.2 and must be changed together, in one commit, or not at all.
Why they are kept equal rather than allowed to drift apart: they were 25.2.4 here and
25.0.2 in the native module for a while, which technically works - native/pom.xml's
dependencyManagement pins the org.graalvm.* coordinates for the image - but it means
engine bytecode compiled against one Truffle API runs against another inside the
image, and the only thing standing between that and a NoSuchMethodError is nobody
having reached for the newer API yet. Aligning them removes the whole question.
Why 25.0.2 specifically: it is the newest MAINLINE GraalVM CE release that exists as a
distribution, so it is the one every consumer can actually install - graalvm/setup-graalvm
fetches jdk-25.0.2 in CI, and Homebrew's graalvm-community-jdk25 cask is 25.0.2. The
intermediate line (25.1.x/25.2.x) ships tarballs from the graalvm-ce-builds releases
page and nowhere else, so pinning it makes a local native build start with a hand
download. See native/pom.xml's native.graalvm.version comment for the full table,
including why 25.0.3 and 25.0.4 look pinnable and are not.
A builder/artifact skew fails the native build at feature registration with
NoSuchMethodError OptimizedTruffleRuntime.getLoopNodeFactory(), which names neither
side of the mismatch; it has shipped to main twice.
.github/scripts/check-native-graalvm-pin.py fails the always-on `lint` job whenever
native.graalvm.version and native-image.yml disagree.
-->
<graalvm.version>25.0.2</graalvm.version>
<!--
Bumping this requires re-checking several things LSMVectorIndex relies on that jvector does not
contractually guarantee across versions:
- GraphIndexBuilder.build() is unrolled by hand in buildGraphFromScratchExclusively() (see the
MAINTENANCE comment at that unroll) to make the insertion/cleanup phase boundary observable.
- GraphIndexBuilder.cleanup() is wrapped in its own tracked submit()/join() the same way, because
cleanup() does the identical external-join shape internally (see the MAINTENANCE comment at that
wrapper) - re-check its two internal parallelExecutor.submit(...).join() calls are still there
and in the same order.
- buildGraphFromScratchExclusively()'s CancellationException handler (issue #5872) skips
GraphIndexBuilder.close() on the fallback path where releaseBackgroundResources() forces an
in-flight build's join() to unblock while a pool worker may still be running. That is safe only
because every GraphIndexBuilder this engine constructs backs onto OnHeapGraphIndex, whose
View.close() is a documented no-op as of 4.0.0-rc.9 - re-verify that close() still touches no
live state before relying on it after a version bump.
-->
<jvector.version>4.0.0-rc.9</jvector.version>
<spatial4j.version>0.8</spatial4j.version>
<jts-core.version>1.20.0</jts-core.version>
<buildnumber-maven-plugin.version>3.3.0</buildnumber-maven-plugin.version>
<!-- Drives both the antlr4-maven-plugin that generates the engine's own grammar
and the matching antlr4-runtime, so the generator and runtime versions must
stay equal. Free to track the latest ANTLR and should keep doing so.
Intentionally independent of gremlin/pom.xml, which is frozen at 4.9.1 by
TinkerPop; see the comment there and #5535 before assuming the two should
converge. -->
<antlr4.version>4.13.2</antlr4.version>
<antlr4.visitor>true</antlr4.visitor>
<cucumber.version>7.34.7</cucumber.version>
<jmh.version>1.37</jmh.version>
</properties>
<build>
<resources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>${buildnumber-maven-plugin.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- JavaCC plugin removed - now using ANTLR4 for SQL parsing -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>${maven-resources-plugin.version}</version>
</plugin>
<plugin>
<groupId>org.antlr</groupId>
<artifactId>antlr4-maven-plugin</artifactId>
<version>${antlr4.version}</version>
<executions>
<execution>
<goals>
<goal>antlr4</goal>
</goals>
<configuration>
<sourceDirectory>${basedir}/src/main/antlr4</sourceDirectory>
<outputDirectory>${basedir}/target/generated-sources/antlr4</outputDirectory>
<visitor>true</visitor>
<listener>true</listener>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-bom</artifactId>
<version>${cucumber.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- SLF4J facade only. ArcadeDB logs through slf4j-api and pins NO binding, so an embedding
application routes the engine's logs through whatever backend it already uses (Logback,
Log4j2, reload4j, or java.util.logging via slf4j-jdk14) with no dependency exclusions. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>com.conversantmedia</groupId>
<artifactId>disruptor</artifactId>
<version>${disruptor.version}</version>
</dependency>
<dependency>
<groupId>at.yawk.lz4</groupId>
<artifactId>lz4-java</artifactId>
<version>${lz4-java.version}</version>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-analysis-common</artifactId>
<version>${lucene.version}</version>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-spatial-extras</artifactId>
<version>${lucene.version}</version>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-queryparser</artifactId>
<version>${lucene.version}</version>
</dependency>
<dependency>
<groupId>org.locationtech.spatial4j</groupId>
<artifactId>spatial4j</artifactId>
<version>${spatial4j.version}</version>
</dependency>
<dependency>
<groupId>org.locationtech.jts</groupId>
<artifactId>jts-core</artifactId>
<version>${jts-core.version}</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>${gson.version}</version>
</dependency>
<dependency>
<groupId>io.github.jbellis</groupId>
<artifactId>jvector</artifactId>
<version>${jvector.version}</version>
</dependency>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-runtime</artifactId>
<version>${antlr4.version}</version>
</dependency>
<dependency>
<groupId>org.graalvm.sdk</groupId>
<artifactId>graal-sdk</artifactId>
<version>${graalvm.version}</version>
</dependency>
<dependency>
<groupId>org.graalvm.polyglot</groupId>
<artifactId>polyglot</artifactId>
<version>${graalvm.version}</version>
</dependency>
<dependency>
<groupId>org.graalvm.polyglot</groupId>
<artifactId>js</artifactId>
<version>${graalvm.version}</version>
<type>pom</type>
</dependency>
<!-- JMH for microbenchmarks -->
<dependency>
<groupId>org.openjdk.jmh</groupId>
<artifactId>jmh-core</artifactId>
<version>${jmh.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.openjdk.jmh</groupId>
<artifactId>jmh-generator-annprocess</artifactId>
<version>${jmh.version}</version>
<scope>test</scope>
</dependency>
<!-- Micrometer for benchmark metrics -->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-core</artifactId>
<version>${micrometer.version}</version>
<scope>test</scope>
</dependency>
<!-- Cucumber for OpenCypher TCK -->
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit-platform-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-suite</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>