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"
         child.project.url.inherit.append.path="false">
    <modelVersion>4.0.0</modelVersion>

    <!-- The coordinates ADR-0002 chose, under the namespace RESTest 1.x is published in on Maven
         Central as es.us.isa:restest. The Java packages stay io.restest. ADR-0044. -->
    <groupId>es.us.isa.restest</groupId>
    <artifactId>restest</artifactId>
    <version>2.5.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <name>RESTest</name>
    <description>Black-box testing tool for REST APIs</description>
    <!-- Every module's address too, and its <scm> below: the child.*.inherit.append.path attributes
         on <project> and <scm> stop Maven adding the module's name to the end of each, which would
         make the page Maven Central shows for restest-core link
         https://github.com/isa-group/RESTest/restest-core, which does not exist. -->
    <url>https://github.com/isa-group/RESTest</url>
    <inceptionYear>2026</inceptionYear>

    <licenses>
        <license>
            <name>Apache License, Version 2.0</name>
            <url>https://www.apache.org/licenses/LICENSE-2.0</url>
            <distribution>repo</distribution>
        </license>
    </licenses>

    <organization>
        <name>ISA Research Group, Universidad de Sevilla</name>
        <url>https://www.isa.us.es</url>
    </organization>

    <developers>
        <developer>
            <id>sergiosegura</id>
            <name>Sergio Segura</name>
            <email>sergiosegura@us.es</email>
            <organization>Universidad de Sevilla</organization>
            <roles><role>maintainer</role></roles>
        </developer>
    </developers>

    <scm child.scm.connection.inherit.append.path="false"
         child.scm.developerConnection.inherit.append.path="false"
         child.scm.url.inherit.append.path="false">
        <connection>scm:git:https://github.com/isa-group/RESTest.git</connection>
        <developerConnection>scm:git:https://github.com/isa-group/RESTest.git</developerConnection>
        <url>https://github.com/isa-group/RESTest</url>
        <tag>HEAD</tag>
    </scm>

    <modules>
        <module>restest-core</module>
        <module>restest-spec</module>
        <module>restest-gen</module>
        <module>restest-exec</module>
        <module>restest-store</module>
        <module>restest-oracles</module>
        <module>restest-report</module>
        <module>restest-cli</module>
        <!-- Verification only: not published, depends on all eight. See ADR-0004. -->
        <module>restest-arch-tests</module>
    </modules>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <!-- Every module targets Java 21, restest-cli included (ADR-0003). -->
        <maven.compiler.release>21</maven.compiler.release>

        <!-- Versions fixed by the stack table in docs/DESIGN.md. -->
        <junit.version>6.1.3</junit.version>
        <assertj.version>3.27.7</assertj.version>
        <archunit.version>1.5.0</archunit.version>
        <jacoco.version>0.8.15</jacoco.version>
        <picocli.version>4.7.7</picocli.version>
        <testcontainers.version>2.0.5</testcontainers.version>
        <swagger-parser.version>2.1.47</swagger-parser.version>
        <!-- Arrives transitively through swagger-parser; pinned in its own right so a future
             swagger-parser upgrade that changes it is a visible, reviewed version bump rather than
             whatever Maven's dependency mediation happens to resolve (ADR-0007's own complaint about
             RESTest 1.x's undeclared swagger-parser dependency, repeated one level down). -->
        <snakeyaml.version>2.6</snakeyaml.version>
        <!-- Same reasoning as snakeyaml below: restest-spec's own source writes the parsed document
             back out with io.swagger.v3.core.util.Json, so the library that provides it is pinned
             here rather than left to whatever swagger-parser happens to resolve. Must move with
             swagger-parser: the two share the model classes they serialise. -->
        <swagger-core.version>2.2.52</swagger-core.version>
        <okhttp.version>5.5.0</okhttp.version>
        <wiremock.version>3.13.2</wiremock.version>
        <sqlite.version>3.50.3.0</sqlite.version>
        <!-- Jackson 2, every module of it at one version. RESTest's own JSON reading uses its
             jackson-core; swagger-parser and swagger-core bring jackson-databind and the YAML and
             date modules, and WireMock, a test dependency, brings its own. Managed through Jackson's
             BOM below rather than left to Maven's mediation, which picks the nearest path: in
             restest-cli that was WireMock's, so a release carried an older jackson-databind than
             the one swagger-core asks for. -->
        <jackson.version>2.22.3</jackson.version>
        <!-- Versioned separately from the rest of Jackson, shared by Jackson 2 and Jackson 3, and
             pinned here for a reason found the hard way: the schema validator's own JSON library
             needed 2.22 while another path through the tree asked for 2.20, and Maven's mediation
             picked the nearer one. The result was a class missing at runtime in the one module that
             has every other module on its class path. Both Jackson BOMs below name a version of it
             now, and when two imported BOMs disagree the one written first wins without a word, so
             it stays pinned: one written decision, which has to be the version both of them name.
             Same reasoning as snakeyaml below; a worse failure, because it only shows up when
             everything is assembled. -->
        <jackson-annotations.version>2.22</jackson-annotations.version>
        <json-schema-validator.version>3.0.7</json-schema-validator.version>
        <!-- Jackson 3, a separate line under the tools.jackson group, which only the schema
             validator brings in, and which reads every JSON reply it checks and the specification document.
             Managed here, rather than left at whatever the validator asks for, so that a fix to it
             is one line here and does not wait for a validator release: 3.0.7 asks for 3.2.1, which
             has denial-of-service flaws fixed in 3.2.3. Each 3.x release names the
             jackson-annotations it needs, and that has to stay the version pinned above. -->
        <jackson3.version>3.2.3</jackson3.version>
        <!-- Builds a string that matches a regular expression, which is what a specification's
             `pattern` asks for. Carries no dependencies of its own, and takes the run's own seeded
             java.util.random.RandomGenerator, so a run built on it is still repeated exactly. -->
        <rgxgen.version>3.0</rgxgen.version>
        <slf4j.version>2.0.17</slf4j.version>
        <!-- Three libraries the OpenAPI parser and the HTTP client bring, pinned at the versions the
             release archive carries; the comment on them below says why. -->
        <guava.version>33.5.0-jre</guava.version>
        <commons-codec.version>1.19.0</commons-codec.version>
        <jetbrains-annotations.version>17.0.0</jetbrains-annotations.version>
        <!-- Properties so that dist/central.sh asks for these two plugins at the versions the build
             uses, rather than for whatever Maven finds newest. -->
        <maven-dependency-plugin.version>3.8.1</maven-dependency-plugin.version>
        <maven-help-plugin.version>3.5.2</maven-help-plugin.version>
        <pitest.version>1.30.0</pitest.version>
        <pitest-junit5.version>1.2.3</pitest-junit5.version>

        <!--
          Default for the JVM arguments surefire passes on. JaCoCo's prepare-agent goal replaces
          this with the agent it needs, so a module adding its own argument writes
          "@{argLine} ..." and keeps coverage working; this empty default is what stops that
          reference from failing to resolve when coverage is switched off.
        -->
        <argLine></argLine>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.junit</groupId>
                <artifactId>junit-bom</artifactId>
                <version>${junit.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.assertj</groupId>
                <artifactId>assertj-core</artifactId>
                <version>${assertj.version}</version>
            </dependency>
            <dependency>
                <groupId>com.tngtech.archunit</groupId>
                <artifactId>archunit-junit5</artifactId>
                <version>${archunit.version}</version>
            </dependency>
            <!--
              Containerised APIs for the smoke run. The JUnit integration is `testcontainers-junit-
              jupiter` since the 2.x line; `org.testcontainers:junit-jupiter`, which every 1.x
              example on the internet names, has no 2.x release at all and fails to resolve.
            -->
            <dependency>
                <groupId>org.testcontainers</groupId>
                <artifactId>testcontainers</artifactId>
                <version>${testcontainers.version}</version>
            </dependency>
            <dependency>
                <groupId>org.testcontainers</groupId>
                <artifactId>testcontainers-junit-jupiter</artifactId>
                <version>${testcontainers.version}</version>
            </dependency>
            <dependency>
                <groupId>info.picocli</groupId>
                <artifactId>picocli</artifactId>
                <version>${picocli.version}</version>
            </dependency>
            <dependency>
                <groupId>io.swagger.parser.v3</groupId>
                <artifactId>swagger-parser</artifactId>
                <version>${swagger-parser.version}</version>
            </dependency>
            <dependency>
                <groupId>io.swagger.core.v3</groupId>
                <artifactId>swagger-core</artifactId>
                <version>${swagger-core.version}</version>
            </dependency>
            <dependency>
                <groupId>org.yaml</groupId>
                <artifactId>snakeyaml</artifactId>
                <version>${snakeyaml.version}</version>
            </dependency>
            <dependency>
                <groupId>com.squareup.okhttp3</groupId>
                <artifactId>okhttp-bom</artifactId>
                <version>${okhttp.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.wiremock</groupId>
                <artifactId>wiremock</artifactId>
                <version>${wiremock.version}</version>
            </dependency>
            <dependency>
                <groupId>org.xerial</groupId>
                <artifactId>sqlite-jdbc</artifactId>
                <version>${sqlite.version}</version>
            </dependency>
            <dependency>
                <groupId>com.fasterxml.jackson</groupId>
                <artifactId>jackson-bom</artifactId>
                <version>${jackson.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.fasterxml.jackson.core</groupId>
                <artifactId>jackson-annotations</artifactId>
                <version>${jackson-annotations.version}</version>
            </dependency>
            <dependency>
                <groupId>com.networknt</groupId>
                <artifactId>json-schema-validator</artifactId>
                <version>${json-schema-validator.version}</version>
            </dependency>
            <dependency>
                <groupId>tools.jackson</groupId>
                <artifactId>jackson-bom</artifactId>
                <version>${jackson3.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.github.curious-odd-man</groupId>
                <artifactId>rgxgen</artifactId>
                <version>${rgxgen.version}</version>
            </dependency>
            <!-- Arrives through the schema validator, which logs through the SLF4J facade. Without a
                 binding, SLF4J prints three warning lines to standard error on first use, which is
                 not an acceptable first impression of a command-line tool. Choosing the binding is
                 the application's business, so restest-cli takes the do-nothing one at runtime; no
                 library here picks one. -->
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-nop</artifactId>
                <version>${slf4j.version}</version>
            </dependency>
            <!--
                 The facade itself, pinned for a reason that only shows up once two things want it.
                 Testcontainers asks for 1.7.36; the do-nothing binding above is 2.0.x. Both sit the
                 same distance from restest-cli, so Maven's nearest-wins rule does not decide between
                 them and the order the dependencies happen to be written in does. A 1.7 facade with
                 a 2.0 binding does not work, and it does not fail the build either: it prints the
                 very warnings the binding was added to silence and then logs nothing. One managed
                 version makes the answer the same whatever order anybody writes.
            -->
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>${slf4j.version}</version>
            </dependency>
            <!--
                 Pinned at the versions the release archive carries, so that what it carries does
                 not depend on a test library. Without a pin each came in at the version WireMock or
                 Testcontainers asks for, nearer the top of restest-cli's tree than the OpenAPI
                 parser that asks for an older one, and the POMs of the modules that do not have
                 those test libraries would have named the parser's (ADR-0044 §3). dist/central.sh
                 refuses a module whose libraries differ from restest-cli's, which is how the next
                 one is found.
            -->
            <dependency>
                <groupId>com.google.guava</groupId>
                <artifactId>guava</artifactId>
                <version>${guava.version}</version>
            </dependency>
            <dependency>
                <groupId>commons-codec</groupId>
                <artifactId>commons-codec</artifactId>
                <version>${commons-codec.version}</version>
            </dependency>
            <dependency>
                <groupId>org.jetbrains</groupId>
                <artifactId>annotations</artifactId>
                <version>${jetbrains-annotations.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <!--
      Inherited by every module so each one is test-ready without repeating itself.
      Test scope only: a test framework at compile scope becomes part of the published
      surface, which is one of the 1.x mistakes ADR-0004 sets out to prevent.
    -->
    <dependencies>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-launcher</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.13.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>3.5.4</version>
                    <configuration>
                        <!--
                          Tests run on the classpath, not the module path. The module boundaries
                          are enforced where they matter - main compilation, plus the ArchUnit
                          rules in restest-arch-tests - and running tests as named modules would
                          buy nothing but patch-module ceremony. The module-info check in
                          SourceTreeRulesTest asserts that no module quietly loses its
                          module-info.java as a result.
                        -->
                        <useModulePath>false</useModulePath>
                        <!--
                          The smoke run starts two containers and pulls about 160 MB the first time.
                          `./mvnw verify` is the command everybody runs all day and on all nine
                          continuous-integration rows, so it does not do that: the tagged tests are
                          left out here and selected back in by the `smoke` and `it` profiles. Six
                          of the nine rows could not run them anyway - macOS runners have no
                          container runtime and Windows runners only run Windows containers.
                        -->
                        <excludedGroups>smoke</excludedGroups>
                        <!--
                          A key left in RESTEST_AUTH on the machine running the build would be read
                          by every test that starts the command, and change what those tests send -
                          or have them refuse to start. The tests that are about that variable hand
                          the command an environment of their own instead.
                        -->
                        <excludedEnvironmentVariables>RESTEST_AUTH</excludedEnvironmentVariables>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-clean-plugin</artifactId>
                    <version>3.2.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-dependency-plugin</artifactId>
                    <version>${maven-dependency-plugin.version}</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-help-plugin</artifactId>
                    <version>${maven-help-plugin.version}</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-jar-plugin</artifactId>
                    <version>3.4.2</version>
                    <configuration>
                        <archive>
                            <manifest>
                                <!--
                                  Stamps Implementation-Title/Version/Vendor-Id into every jar. Not
                                  the default, and its absence is not cosmetic: a run's JSON report
                                  says which RESTest produced it by reading this, and with nothing
                                  to read it says "unknown". A report that cannot name its own
                                  version is no use for comparing the runs of two versions.
                                -->
                                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                            </manifest>
                        </archive>
                    </configuration>
                </plugin>
                <!-- The sources and the Javadoc Maven Central asks for, each jar saying which RESTest
                     it belongs to, as the jar plugin's above does. -->
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-source-plugin</artifactId>
                    <version>3.4.0</version>
                    <configuration>
                        <archive>
                            <manifest>
                                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                            </manifest>
                        </archive>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-javadoc-plugin</artifactId>
                    <version>3.12.0</version>
                    <configuration>
                        <archive>
                            <manifest>
                                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                            </manifest>
                        </archive>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>flatten-maven-plugin</artifactId>
                    <version>1.8.0</version>
                </plugin>
                <plugin>
                    <groupId>org.jacoco</groupId>
                    <artifactId>jacoco-maven-plugin</artifactId>
                    <version>${jacoco.version}</version>
                </plugin>
                <plugin>
                    <groupId>org.pitest</groupId>
                    <artifactId>pitest-maven</artifactId>
                    <version>${pitest.version}</version>
                    <dependencies>
                        <dependency>
                            <groupId>org.pitest</groupId>
                            <artifactId>pitest-junit5-plugin</artifactId>
                            <version>${pitest-junit5.version}</version>
                        </dependency>
                    </dependencies>
                </plugin>
            </plugins>
        </pluginManagement>

        <plugins>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>prepare-agent</id>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                    <!--
                      Measured everywhere, blocking on two modules. `check` executions live in
                      restest-core/pom.xml and restest-oracles/pom.xml - the two modules
                      docs/DESIGN.md names under "Quality gates" - rather than here, because a
                      minimum imposed on every module would be a different promise from the one
                      that was made, and would have to be set low enough to be worthless.

                      Everywhere else the agent is attached and `report` runs, so a module's
                      coverage is visible without being enforced. A module with no tests produces
                      no execution data and the report goal skips, saying so. See docs/ci.md.
                    -->
                </executions>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <!--
          Asking for no tests asks for no coverage check. The two modules with a blocking minimum
          would otherwise fail a `-DskipTests` build for having covered nothing - which is true, and
          is not news: nothing was run. Continuous integration never skips tests, so the gate is
          never skipped where it matters. Both spellings are covered because both are in common use.
        -->
        <profile>
            <id>tests-skipped</id>
            <activation>
                <property>
                    <name>skipTests</name>
                    <value>true</value>
                </property>
            </activation>
            <properties>
                <jacoco.skip>true</jacoco.skip>
            </properties>
        </profile>
        <profile>
            <id>tests-not-even-built</id>
            <activation>
                <property>
                    <name>maven.test.skip</name>
                    <value>true</value>
                </property>
            </activation>
            <properties>
                <jacoco.skip>true</jacoco.skip>
            </properties>
        </profile>

        <!--
          Just the smoke run: the whole tool, from the command line, against two real APIs in
          containers. Nothing else runs, so coverage is switched off for the same reason the two
          profiles above switch it off - the two modules with a blocking minimum would be measured
          at nothing, which is not news when nothing was run.

          The property is what turns a missing container runtime from a skipped test into a failed
          build. Asking for this profile is asking for the containers; a gate that quietly reports
          success because it could not run is worse than no gate, because it looks like one.
        -->
        <profile>
            <id>smoke</id>
            <properties>
                <jacoco.skip>true</jacoco.skip>
            </properties>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <groups>smoke</groups>
                            <excludedGroups>none</excludedGroups>
                            <failIfNoTests>false</failIfNoTests>
                            <systemPropertyVariables>
                                <restest.smoke.required>true</restest.smoke.required>
                            </systemPropertyVariables>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!--
          Everything, containers included: the ordinary build plus the smoke run. `none` is a tag no
          test carries, which is how "exclude nothing" is written without relying on what an empty
          element means to the plugin.
        -->
        <profile>
            <id>it</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <excludedGroups>none</excludedGroups>
                            <systemPropertyVariables>
                                <restest.smoke.required>true</restest.smoke.required>
                            </systemPropertyVariables>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!--
          What Maven Central gets beside each module's jar, which dist/central.sh lays out and the
          release workflow signs and uploads; a profile, so that the build everybody runs all day
          writes no Javadoc. The POM Central gets is not pom.xml: dist/central.sh writes it from the
          two files made here, the module's POM flattened, for its name, address, licence and the
          rest with nothing inherited, and the list of libraries Maven resolved for the module, the
          list that fills restest-cli's target/lib. ADR-0044 §3 says why the list is not left to
          pom.xml's own dependencies, nor to flatten-maven-plugin.
        -->
        <profile>
            <id>central</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>sources-for-central</id>
                                <goals>
                                    <goal>jar-no-fork</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>javadoc-for-central</id>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>flatten-maven-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>pom-for-central</id>
                                <!-- The goal binds to no phase of its own. -->
                                <phase>package</phase>
                                <goals>
                                    <goal>flatten</goal>
                                </goals>
                            </execution>
                        </executions>
                        <configuration>
                            <flattenMode>ossrh</flattenMode>
                            <updatePomFile>false</updatePomFile>
                            <outputDirectory>${project.build.directory}</outputDirectory>
                            <flattenedPomFilename>flattened-pom.xml</flattenedPomFilename>
                        </configuration>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-dependency-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>libraries-for-central</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>list</goal>
                                </goals>
                                <configuration>
                                    <includeScope>runtime</includeScope>
                                    <sort>true</sort>
                                    <outputFile>${project.build.directory}/runtime-dependencies.txt</outputFile>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>