Description

<dependency>
    <groupId>org.cassandraunit</groupId>
    <artifactId>cassandra-unit</artifactId>
    <version>5.4.0</version>
</dependency>

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.cassandraunit</groupId>
        <artifactId>cassandra-unit-parent</artifactId>
        <version>5.4.0</version>
    </parent>
    <groupId>org.cassandraunit</groupId>
    <artifactId>cassandra-unit</artifactId>
    <packaging>jar</packaging>
    <name>cassandra-unit</name>
    <description>An embedded Apache Cassandra you can start from a test, preloaded with your test data</description>

    <dependencies>

        <!--
          The fixture layer: CQLDataLoader, the dataset types and the parsers.

          Compile scope, not runtime, and that is deliberate: everything it exports stays on the
          compile classpath of anyone depending on cassandra-unit, so org.cassandraunit.dataset.*
          and CQLDataLoader resolve exactly as they did when they lived here and no consumer has to
          touch an import.

          It carries java-driver-core, jackson-databind, snakeyaml, slf4j-api and the optional
          jackson-dataformat-csv, which is why those are no longer declared below.
        -->
        <dependency>
            <groupId>org.cassandraunit</groupId>
            <artifactId>cassandra-unit-dataset</artifactId>
            <version>${project.version}</version>
        </dependency>

        <!--
          JUnit 4 and JUnit 5 are both optional: this module ships an integration for each
          (CassandraCQLUnit as a @Rule, CassandraUnitExtension as an Extension) and the
          consumer's own test platform decides which one is on the classpath. Prior versions
          declared JUnit 4 at compile scope, which leaked it onto every consumer.
        -->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${cu.junit.version}</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-api</artifactId>
            <version>${cu.junit.jupiter.version}</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.apache.cassandra</groupId>
            <artifactId>cassandra-all</artifactId>
            <version>${cu.cassandra.all.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>log4j-over-slf4j</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>log4j</groupId>
                    <artifactId>log4j</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.httpcomponents</groupId>
                    <artifactId>httpcore</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.httpcomponents</groupId>
                    <artifactId>httpclient</artifactId>
                </exclusion>
                <exclusion> <!-- ST4 and stringtemplate seem to contain the same classes... ST4 is newer -->
                    <groupId>org.antlr</groupId>
                    <artifactId>stringtemplate</artifactId>
                </exclusion>
                <!--
                  cassandra-all drags in the legacy shaded 3.12.1 driver, which exposes the old
                  com.datastax.driver.core.* API. Different coordinates from java-driver-core, so
                  Maven never mediates between the two and both would reach the consumer's compile
                  classpath - two CQL driver APIs, silently. Nothing on the embedded-daemon path
                  needs it: the full suite passes with it excluded.
                -->
                <exclusion>
                    <groupId>org.apache.cassandra</groupId>
                    <artifactId>cassandra-driver-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <!--
          The driver is a REQUIRED dependency: CqlSession is imported unconditionally by the
          helper, the loader and the rule. Declaring it <optional> (as prior versions did) is
          what produced the NoClassDefFoundError reports in issues #276 and #304.

          Note the coordinates: the DataStax coordinates (com.datastax.oss) are frozen at
          4.17.0. The driver was donated to Apache and now releases as
          org.apache.cassandra:java-driver-core. The Java packages are unchanged
          (com.datastax.oss.driver.*), so this is a coordinate change only.
        -->
        <dependency>
            <groupId>org.apache.cassandra</groupId>
            <artifactId>java-driver-core</artifactId>
            <version>${cu.cassandra.driver.version}</version>
        </dependency>

        <!--
          Direct compile dependencies of EmbeddedCassandraServerHelper that used to arrive
          transitively via cassandra-all.
        -->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
        </dependency>

        <!-- test -->
        <!--
          Optional in cassandra-unit-dataset, so it is not transitive. CQLDataSetFactoryTest and
          RowsDataSetFormatsLoadTest both load .csv datasets, which is exactly the situation a
          consumer using CSV is in - so exercising it at test scope here is the right shape.
        -->
        <dependency>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-csv</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${cu.junit.jupiter.version}</version>
            <scope>test</scope>
        </dependency>
        <!-- The @Rule integration is still JUnit 4, so its tests need the vintage engine -->
        <dependency>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
            <version>${cu.junit.jupiter.version}</version>
            <scope>test</scope>
        </dependency>
        <!--
          AssertJ is the single assertion API for the whole suite. It is deliberately not tied
          to a test engine: the @Rule tests run on JUnit 4 via the vintage engine and the rest on
          Jupiter, and both use the same assertions.
        -->
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <version>${cu.assertj.version}</version>
            <scope>test</scope>
        </dependency>

        <!-- log -->
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-core</artifactId>
            <version>${cu.logback.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>${cu.logback.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <executions>
                    <execution>
                        <id>enforce-jdk</id>
                        <goals><goal>enforce</goal></goals>
                        <configuration>
                            <rules>
                                <!--
                                  Cassandra 5.0 runs on JDK 11 or 17 only, and the embedded
                                  daemon is started in this JVM, so the build JDK is the
                                  server JDK. We require 17 specifically: maven.compiler.release
                                  is 17, and spring-test 6.2 needs 17 regardless, so supporting
                                  11 would mean split release levels across modules for no gain.
                                  Without this check a wrong JDK shows up as
                                  surefire's "The forked VM terminated without properly
                                  saying goodbye", which says nothing useful. Note that a
                                  jenv shim will override JAVA_HOME for mvn - check
                                  `mvn -v`, not `java -version`.

                                  The upper bound is real, not caution: Cassandra's
                                  ThreadAwareSecurityManager calls System::setSecurityManager,
                                  which is terminally deprecated and throws on JDK 24+.
                                -->
                                <requireJavaVersion>
                                    <version>[17,18)</version>
                                    <message>cassandra-unit must be built and run on JDK 17. Cassandra 5.0 supports only JDK 11 and 17, and this project targets 17 (spring-test 6.2 requires it too). The embedded daemon runs in the build JVM, so this is the server JDK as well. If this looks wrong, check `mvn -v` - a jenv shim overrides JAVA_HOME for mvn.</message>
                                </requireJavaVersion>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

        </plugins>
    </build>
</project>