Description

<dependency>
    <groupId>net.cumba</groupId>
    <artifactId>cumba-oss-corej-core</artifactId>
    <version>0.5.0</version>
</dependency>

<?xml version="1.0" encoding="UTF-8"?>
<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>net.cumba</groupId>
        <artifactId>cumba-oss-corej-parent</artifactId>
        <version>0.5.0</version>
        <relativePath>../../pom.xml</relativePath>
    </parent>

    <artifactId>cumba-oss-corej-core</artifactId>

    <name>Cumba OSS coreJ :: CORE Engine</name>
    <url>https://github.com/cumba-oss/cumba-oss-corej</url>
    <packaging>jar</packaging>

    <inceptionYear>2026</inceptionYear>
    <description>
        CDISC validation rule engine: rule-package loader, check evaluator,
        report assembler and the pluggable report-writer SPI. Ships NO report
        writer of its own - json/json-2 and xlsx live in cumba-oss-corej-report-json
        and cumba-oss-corej-report-xlsx - so the engine carries no Excel dependency.
        Ships the dataviewer's net.cumba.corej.core.* source verbatim.
    </description>

    <properties>
        <!-- Repo-root anchor, depth 2 (see the root pom). -->
        <repo.root.dir>${project.basedir}/../..</repo.root.dir>

        <mockito.agent>-javaagent:${org.mockito:mockito-core:jar}</mockito.agent>
        <pitest.excludedTestClasses>net.cumba.corej.core.exec.JoinCacheConcurrencyTest</pitest.excludedTestClasses>
        <!--
            Mutation ratchet. The parent's defaults (55 / 80) left ~24 points of
            slack over this module's actual score, so coverage added here could
            erode again unnoticed.

            Measured 2026-08-30 on a COLD full-module run (pitest history removed,
            machine otherwise idle): 12 018 / 14 378 mutants killed = 83.6%, line
            coverage (mutated classes only) 21 348 / 23 413 = 91%. A cold run is
            the honest baseline - a warm/incremental run reuses prior verdicts and
            measures slightly higher. The targets below sit a few points under
            each, so ordinary churn does not trip the gate but a real regression
            does. Raise them again as coverage improves - in THIS file, never via
            a command-line -D, which would clobber every module's override at once.

            ⚠⚠ This baseline is only reachable with
            CompiledProgramCacheIsolationExtension active (see its javadoc in the
            test sources). Without it, NativeExprEvaluator's static program cache
            makes pitest attribute each ExprCompiler line to the FIRST test that
            compiled that expression, and the identical measurement reads 82% -
            223 phantom survivors on ExprCompiler alone. If this gate starts
            failing after a test-infrastructure change, check that the extension
            still loads before touching the numbers below.
        -->
        <pitest.mutation.target>80</pitest.mutation.target>
        <pitest.coverage.target>87</pitest.coverage.target>
    </properties>

    <dependencies>

        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-datatable</artifactId>
        </dependency>

        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-datatable-impl</artifactId>
        </dependency>

        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-cdisc-library</artifactId>
        </dependency>

        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-web-api</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>

        <!-- JSpecify nullability annotations (NullAway). -->
        <dependency>
            <groupId>org.jspecify</groupId>
            <artifactId>jspecify</artifactId>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
        </dependency>

        <!-- Define-XML object model + parser. Lightweight (model + jackson-xml); does not depend on
             cumba-oss-corej-core, so no cycle. Lets the engine read define_* operands straight from the
             parsed Define-XML (OdmDefineXMLProvider), bypassing the lossy Define-XML to
             IMetadataLibrary (datatable) conversion. See
             plans/PLAN-define-item-metadata-parity-929-1081.md. -->
        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-cdisc-define</artifactId>
        </dependency>

        <!-- TEST ONLY: the Define-XML -> IMetadataLibrary adapter (DefineMetadataLibrary). In
             production this module never constructs one - StudyValidationService obtains it from
             the datatable manager and wraps it with MetadataLibraryProvider.forDefine. The test
             scope exists so DefineSplitDatasetContractTest can compose the define provider EXACTLY
             as production does (ODM-direct over the datatable-backed fallback) against a real
             Define-XML, rather than guarding a composition nobody runs. Acyclic: this module is not
             a dependency of cumba-oss-datatable-provider-define. -->
        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-datatable-provider-define</artifactId>
            <scope>test</scope>
        </dependency>

        <!-- Reads the Python engine's pickle metadata cache (offline library metadata). -->
        <dependency>
            <groupId>net.razorvine</groupId>
            <artifactId>pickle</artifactId>
        </dependency>

        <!-- TarArchiveInputStream: streams the pickle cache out of a repository source archive
             (HttpArchivePickleSource). Declared explicitly - it used to also arrive transitively
             via poi-ooxml, which left this module in Fix #224 together with the XLSX report
             writer, so this declaration is now the only thing keeping the seeder compiling. -->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-compress</artifactId>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-yaml</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-api</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-params</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
        <!--
            MockTable / TestMetadataFixtures. Both were classes in THIS module's test tree until
            2026-09-01, when the coreJ restructure moved them to
            cumba-oss-datatable-testkit's MAIN tree, repackaged to net.cumba.datatable.testkit.
            255 test files here use one or both.
        -->
        <dependency>
            <groupId>net.cumba</groupId>
            <artifactId>cumba-oss-datatable-testkit</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <!--
                     Publish this module's test helpers as a test-jar.

                     ⚠ As of 2026-09-01 this test-jar has ZERO consumers anywhere in the repo.
                     cumba-oss-corej-rules was the only one and dropped it
                     (the coreJ restructure): MockTable and
                     TestMetadataFixtures left for cumba-oss-datatable-testkit, StubMetadataProvider
                     and SyntheticStringTable were copied into cumba-oss-corej-rules' own test tree.
                     A repo-wide sweep of every tracked pom finds no remaining
                     type=test-jar dependency other than the dependencyManagement entry.

                     It is NOT kept for the former parity module, as an earlier draft of this
                     comment claimed: that directory has zero git-tracked files and no pom.xml,
                     so it is untracked local scratch, not a Maven module.

                     So this execution now builds and installs an artifact nothing consumes.
                     Left in place rather than deleted because removing a published artifact is
                     the owner's call, not a side effect of a restructure — but the reasoning
                     that argued for cutting the consumer argues equally for deleting this.
                -->
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>${plugin.maven-jar-plugin.version}</version>
                <executions>
                    <execution>
                        <id>test-jar</id>
                        <goals>
                            <goal>test-jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <!--
                javadoc cannot see Lombok-generated types. ExprLowering has one
                private method whose signature names CheckConditionLeaf's
                @Builder-generated nested class:

                    applyValue(CheckConditionLeaf.CheckConditionLeafBuilder b, Expr value)

                javadoc reads CheckConditionLeaf from source, where that nested
                class does not exist, so the signature is an unresolvable
                "cannot find symbol". That single error makes javadoc exit 1
                *before writing any HTML*, and the module then ships an empty
                318-byte -javadoc.jar — no documentation for any of its 245
                source files.

                Excluding this one file costs ExprLowering's javadoc page and
                buys back the other 244. It is the only such signature in the
                module (verified by grep, 2026-08-31). Drop this exclusion if
                the javadoc build is ever moved onto delombok-ed sources.
            -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <configuration>
                    <sourceFileExcludes>
                        <sourceFileExclude>net/cumba/corej/core/expr/ExprLowering.java</sourceFileExclude>
                    </sourceFileExcludes>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <!--
                        Override the project-wide target/test-cwd setting back to the module
                        basedir: the curated fixture corpus (src/test/resources/fixtures/rules)
                        and documentation/expression-language-reference.md resolve via
                        module-relative paths (the dataviewer convention these tests
                        originated under).
                    -->
                    <workingDirectory>${project.basedir}</workingDirectory>
                </configuration>
            </plugin>
        </plugins>
    </build>


</project>