pom.xml

<?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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>io.github.jinahya</groupId>
    <artifactId>jinahya-parent</artifactId>
    <version>1.0.9</version>
  </parent>

  <artifactId>assertj-validation</artifactId>
  <version>0.6.2-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>${project.artifactId}</name>
  <description>
    An AssertJ extension for Jakarta Validation: asserts for beans, property values, constraint violations,
    constraint descriptors and property paths.
  </description>
  <url>https://github.com/jinahya/${project.artifactId}</url>
  <inceptionYear>2021</inceptionYear>
  <licenses>
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <developers>
    <developer>
      <name>Jin Kwon</name>
      <email>onacit_at_gmail.com</email>
      <url>https://github.com/onacit</url>
    </developer>
  </developers>

  <scm>
    <url>https://github.com/jinahya/${project.artifactId}</url>
    <tag>HEAD</tag>
  </scm>
  <issueManagement>
    <system>GitHub</system>
    <url>https://github.com/jinahya/${project.artifactId}/issues</url>
  </issueManagement>

  <properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>${maven.compiler.source}</maven.compiler.target>
    <maven.compiler.release>${maven.compiler.target}</maven.compiler.release>
    <maven.compiler.testSource>25</maven.compiler.testSource>
    <maven.compiler.testTarget>${maven.compiler.testSource}</maven.compiler.testTarget>
    <maven.compiler.testRelease>${maven.compiler.testSource}</maven.compiler.testRelease>
    <version.maven.compiler>3.16.0</version.maven.compiler>
    <version.maven.surefire>3.6.0</version.maven.surefire>
    <version.maven.failsafe>${version.maven.surefire}</version.maven.failsafe>

    <!-- Jakarta Validation is the API this module extends, so unlike the test tooling below it is compiled
         against. It stays provided: a consumer already has the API on its classpath, and pinning one version
         here would drag it onto theirs. The generation is an axis, though, so the versions below move together
         and a profile overrides them; see <profiles>.
         The defaults are Jakarta EE 11, which is what jakarta-ee-11 selects. -->
    <!-- https://jakarta.ee/specifications/platform/11/ -->
    <!-- https://central.sonatype.com/artifact/jakarta.platform/jakarta.jakartaee-bom/versions -->
    <!-- 11.0.0 manages: jakarta.validation-api 3.1.1 -->
    <version.jakarta.jakartaee-bom>11.0.0</version.jakarta.jakartaee-bom>
    <!-- the Jakarta Validation specification of the active generation; surefire hands it to the tests, so that
         a test can assert which generation it is running against -->
    <jakarta.validation.spec.version>3.1</jakarta.validation.spec.version>
    <!-- the reference implementation; test-scope only, since this module validates through the API alone -->
    <!-- https://hibernate.org/validator/releases/ -->
    <!-- https://docs.jboss.org/hibernate/validator/9.0/reference/en-US/html_single/#validator-gettingstarted-uel -->
    <!-- hibernate-validator: 9 / expressly: 6 -->
    <version.org.hibernate.validator>9.1.4.Final</version.org.hibernate.validator>
    <!-- https://central.sonatype.com/artifact/org.glassfish.expressly/expressly -->
    <version.org.glassfish.expressly>6.0.0</version.org.glassfish.expressly>

    <version.ch.qos.logback>1.6.5</version.ch.qos.logback>
    <version.org.assertj>4.0.0-M1</version.org.assertj>
    <!-- held at 5.x until Mockito moves. mockito-junit-jupiter 5.24.0 still declares junit-jupiter-api 5.13.4,
         so junit-bom 6.x does not update Mockito's JUnit integration, it overrides it: the BOM pulls the API up
         to 6.x under a Mockito artifact built and tested against 5.x. It passes here only because these tests
         use Mockito through Mockito.spy/when and never MockitoExtension, which is the surface that would break
         first — a thin reason to run an unsupported pairing. versions:display-property-updates goes on offering
         6.x on purpose; take it once mockito-junit-jupiter declares junit-jupiter-api 6. -->
    <version.org.junit>5.14.4</version.org.junit>
    <version.org.mockito>5.24.0</version.org.mockito>
    <!-- test-scope only, and on the annotation processor path of the test compilation alone; see <build> -->
    <version.org.projectlombok>1.18.48</version.org.projectlombok>
    <version.org.slf4j>2.0.20</version.org.slf4j>
  </properties>

  <dependencyManagement>
    <!-- sorted by groupId, then artifactId -->
    <dependencies>
      <dependency>
        <groupId>jakarta.platform</groupId>
        <artifactId>jakarta.jakartaee-bom</artifactId>
        <version>${version.jakarta.jakartaee-bom}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.assertj</groupId>
        <artifactId>assertj-bom</artifactId>
        <version>${version.org.assertj}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.junit</groupId>
        <artifactId>junit-bom</artifactId>
        <version>${version.org.junit}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-bom</artifactId>
        <version>${version.org.mockito}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-bom</artifactId>
        <version>${version.org.slf4j}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <!-- sorted by groupId, then artifactId; what a scope means here:
         provided - the two APIs this module sits between, Jakarta Validation and AssertJ. Both are compiled
                    against, and a consumer of this module already has both, at versions of its own choosing.
         test     - the test tooling, and the validation engine: nothing in main references an implementation,
                    which is the point of extending the API rather than Hibernate Validator. -->
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>${version.ch.qos.logback}</version>
      <scope>test</scope>
    </dependency>
    <!-- the API this module extends; its version is pinned by the active jakarta-ee-NN profile -->
    <dependency>
      <groupId>jakarta.validation</groupId>
      <artifactId>jakarta.validation-api</artifactId>
      <scope>provided</scope>
    </dependency>
    <!-- the other API this module extends -->
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-core</artifactId>
      <scope>provided</scope>
      <exclusions>
        <!-- assertj pins an older byte-buddy than mockito needs; let mockito's own version win. The exclusion is
             declared here, rather than in <dependencyManagement>, because assertj-bom is an import and an import
             carries no exclusions: only the versions it manages are read, and anything else on the entry is
             ignored. Dropping it would hand the resolution to declaration order, where org.assertj sorts ahead of
             org.mockito, and the older version would win -->
        <exclusion>
          <groupId>net.bytebuddy</groupId>
          <artifactId>byte-buddy</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <!-- the expression language Hibernate Validator resolves message templates with -->
    <dependency>
      <groupId>org.glassfish.expressly</groupId>
      <artifactId>expressly</artifactId>
      <version>${version.org.glassfish.expressly}</version>
      <scope>test</scope>
    </dependency>
    <!-- the reference implementation the tests validate through -->
    <dependency>
      <groupId>org.hibernate.validator</groupId>
      <artifactId>hibernate-validator</artifactId>
      <version>${version.org.hibernate.validator}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</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>
    <!-- the annotations only; the processor which acts on them is put on the processor path of the test
         compilation, in <build>, and never on the compile classpath -->
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <version>${version.org.projectlombok}</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build><!-- sorted by groupId, then artifactId, as the two dependency blocks above are. Sorting plugins is only
         safe where declaration order carries no meaning, and here it carries none: Maven falls back to POM
         order for executions bound to the SAME phase, and no two plugins below share one — compiler is at
         compile/test-compile, surefire at test, jar at package, and javadoc and versions declare no execution
         at all. Add an execution that collides with an existing phase and the order stops being free, so
         pin the pair's relative position then and say why.
         None of these carry a <version> they do not need: versions-maven-plugin and maven-javadoc-plugin
         merge their configuration onto the parent's declaration, which already pins them. -->
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${version.maven.compiler}</version>
        <executions>
          <!-- Lombok is put on the processor path of the test compilation, and of that one alone: no class under
               src/main uses it, and a processor path declared on the plugin rather than on an execution would apply
               to the main compilation too. Declaring the path at all is also what enables annotation processing,
               since javac runs no processor it merely finds on the classpath, so the main compilation goes on
               running with no processor at all, which is what it wants. -->
          <execution>
            <id>default-testCompile</id>
            <configuration>
              <annotationProcessorPaths>
                <path>
                  <groupId>org.projectlombok</groupId>
                  <artifactId>lombok</artifactId>
                  <version>${version.org.projectlombok}</version>
                </path>
              </annotationProcessorPaths>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifestEntries>
              <Automatic-Module-Name>com.github.jinahya.assertj.validation</Automatic-Module-Name>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <configuration>
          <links>
            <link>https://javadoc.io/static/org.assertj/assertj-core/${version.org.assertj}</link>
            <link>https://jakarta.ee/specifications/bean-validation/${jakarta.validation.spec.version}/apidocs/</link>
          </links>
          <!-- @apiNote, @implSpec and @implNote are documented by JEP 8068562, yet the standard
               doclet registers none of them for code outside the JDK: left alone, every one of
               them is rejected as an "unknown tag". They are registered here, in the order, and
               with the headings, the JDK itself uses. -->
          <tags>
            <tag>
              <name>apiNote</name>
              <placement>a</placement>
              <head>API Note:</head>
            </tag>
            <tag>
              <name>implSpec</name>
              <placement>a</placement>
              <head>Implementation Requirements:</head>
            </tag>
            <tag>
              <name>implNote</name>
              <placement>a</placement>
              <head>Implementation Note:</head>
            </tag>
          </tags>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>${version.maven.surefire}</version>
        <configuration>
          <systemPropertyVariables>
            <jakarta.validation.spec.version>${jakarta.validation.spec.version}</jakarta.validation.spec.version>
          </systemPropertyVariables>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>versions-maven-plugin</artifactId>
        <configuration>
          <!-- Nothing here should be offered a pre-release. Two reasons, and the second is the one that
               bites: a build does not want to track someone else's beta, and Maven orders a qualifier
               BELOW the release it precedes, so 11.0.0-RC1 sits inside the range [10,11) that the
               jakarta-ee-10 profile uses to stay on generation 10. Ranges alone therefore do not hold
               the generation line; this does. -->
          <ignoredVersions>
            <ignoredVersion>(?i).*[-.](alpha|beta|m|rc|cr)[-.]?\d*</ignoredVersion>
          </ignoredVersions>
        </configuration>
      </plugin>
    </plugins>
  </build>

  <profiles>
    <!-- ============================================== Jakarta EE generation ================ -->
    <!-- The only implementation axis in this build. Jakarta Validation has a single implementation,
         Hibernate Validator with Expressly for the expression language, so a profile does not choose
         an implementation. It chooses a GENERATION, and the three versions that move with it: the
         platform BOM, which pins jakarta.validation-api, and the release of each of those two
         aligned with it.
         The defaults in <properties> are jakarta-ee-11's, so that profile overrides nothing, while
         jakarta-ee-10 overrides all three. Unlike the sibling builds, the API here is compiled
         against rather than merely read reflectively, so the profile also decides what the main
         sources see: 3.1 adds no member this module uses, which is why one source tree serves both.

         Each profile also pins its three axis properties to a MAJOR RANGE for versions-maven-plugin.
         Left alone the plugin reads each property on its own and, under jakarta-ee-10, proposes
         jakartaee-bom 10 -> 11, hibernate-validator 8 -> 9 and expressly 5 -> 6 — which would not
         update that profile so much as collapse it into a copy of jakarta-ee-11. The ranges keep
         versions:update-properties inside the generation, so it still offers the patch releases that
         matter (8.0.3 -> 8.0.5) and never the ones that cross. Moving a generation is a deliberate
         edit of these four lines, not something a bulk update does. -->
    <profile>
      <id>jakarta-ee-11</id>
      <!-- https://jakarta.ee/specifications/platform/11/ -->
      <!-- jakarta.validation-api 3.1.1 / hibernate-validator 9 / expressly 6 -->
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <configuration>
              <properties>
                <property>
                  <name>version.jakarta.jakartaee-bom</name>
                  <version>[11,12)</version>
                </property>
                <property>
                  <name>version.org.hibernate.validator</name>
                  <version>[9,10)</version>
                </property>
                <property>
                  <name>version.org.glassfish.expressly</name>
                  <version>[6,7)</version>
                </property>
              </properties>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
    <profile>
      <id>jakarta-ee-10</id>
      <!-- https://jakarta.ee/specifications/platform/10/ -->
      <!-- jakarta.validation-api 3.0.2 / hibernate-validator 8 / expressly 5 -->
      <properties>
        <version.jakarta.jakartaee-bom>10.0.0</version.jakarta.jakartaee-bom>
        <jakarta.validation.spec.version>3.0</jakarta.validation.spec.version>
        <version.org.hibernate.validator>8.0.5.Final</version.org.hibernate.validator>
        <version.org.glassfish.expressly>5.0.0</version.org.glassfish.expressly>
      </properties>
      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <configuration>
              <properties>
                <property>
                  <name>version.jakarta.jakartaee-bom</name>
                  <version>[10,11)</version>
                </property>
                <property>
                  <name>version.org.hibernate.validator</name>
                  <version>[8,9)</version>
                </property>
                <property>
                  <name>version.org.glassfish.expressly</name>
                  <version>[5,6)</version>
                </property>
              </properties>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>