api-sheriff-parent
Used in:
components
- OverviewOverview
- VersionsVersions
- DependentsDependents
- DependenciesDependencies
<dependency>
<groupId>de.cuioss.sheriff.gateway</groupId>
<artifactId>api-sheriff-parent</artifactId>
<version>0.2.3</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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>de.cuioss</groupId>
<artifactId>cui-quarkus-parent</artifactId>
<version>1.7.5</version>
<relativePath />
</parent>
<groupId>de.cuioss.sheriff.gateway</groupId>
<artifactId>api-sheriff-parent</artifactId>
<version>0.2.3</version>
<packaging>pom</packaging>
<!-- Must be declared: <inceptionYear> is inherited, and the license plugin binds
the copyright ${year} to it. Without this, this project would report
cui-parent-pom's 2022 and restamp every header on each -Ppre-commit run. -->
<inceptionYear>2025</inceptionYear>
<name>API Sheriff Parent</name>
<description>An API-Gateway focused on Security and a lightweight approach.
The module provides robust API gateway capabilities with comprehensive security features,
rate limiting, authentication, and authorization in multi-tenant environments.
</description>
<url>https://github.com/cuioss/api-sheriff/</url>
<modules>
<module>api-sheriff</module>
<module>integration-tests</module>
<module>benchmarks</module>
<!-- Demo SPA + Playwright end-to-end suite. Carries no Java and contributes no work to the
default lane: every npm-touching execution lives inside its own 'e2e-demo' profile, so a
standard reactor build walks through it without downloading Node or starting a container.
Placed last so the existing module ordering is untouched. -->
<module>demo-client</module>
<!-- Production-shaped docker-compose sample. Carries no Java and contributes nothing to the
default lane: every inherited Java plugin is switched off, so this leg builds no artifact. -->
<module>deployment</module>
<!-- Published build parent for downstream deployers. Carries NO Java and builds NO artifact:
it exists to be PUBLISHED rather than built, and its value is delivered entirely by
inheritance on a consumer's side. It is listed here so the reactor keeps it releasable
and version-consistent with everything else, not because there is work to do — the
quarkus-maven-plugin goals it binds short-circuit on pom packaging. Its worked example
under build-parent/example is deliberately NOT a module: it is built by hand from the
runbook in doc/user/downstream-parent.adoc, so a native consumer build never enters the
default lane. Placed last so the existing module ordering is untouched. -->
<module>build-parent</module>
</modules>
<scm>
<url>https://github.com/cuioss/api-sheriff/</url>
<connection>
scm:git:https://github.com/cuioss/api-sheriff.git
</connection>
<developerConnection>
scm:git:https://github.com/cuioss/api-sheriff/
</developerConnection>
<tag>0.2.3</tag>
</scm>
<issueManagement>
<url>https://github.com/cuioss/api-sheriff/issues</url>
<system>GitHub Issues</system>
</issueManagement>
<properties>
<version.token-sheriff>0.9.6</version.token-sheriff>
<version.json-schema-validator>3.0.7</version.json-schema-validator>
<!-- Default empty argLine for JaCoCo compatibility - JaCoCo will override this when active -->
<argLine />
<!-- The ONE language-level input (ADR-0001). cui-parent-pom defaults it to 21 and reads it in
maven-compiler-plugin's <release>; cui-java-parent reads the same property in BOTH
maven-javadoc-plugin configurations - the pluginManagement entry behind attach-javadocs and
the pre-commit profile's check-javadocs-pre-commit execution. Overriding the property
moves all three together, which is what the four hand-pinned <release>25</release>
overrides this replaces were approximating: when the parents hardcoded 21, javac and the
javadoc tool could be handed different language levels, and the javadoc tool then failed
on Java 22+ constructs such as unnamed variables that javac accepted. -->
<maven.compiler-plugin.release>25</maven.compiler-plugin.release>
</properties>
<dependencyManagement>
<dependencies>
<!-- version.quarkus is INHERITED from de.cuioss:cui-quarkus-parent - never declared
locally. That parent imports this same BOM, but an inherited import is outranked by
every child-declared one, so it is restated HERE, FIRST, deliberately: it must win
the smallrye-config convergence over java-ee-10-bom and token-sheriff-bom below
(see the token-sheriff-bom comment). Dropping it and relying on the inherited
import silently inverts that precedence - verified as a hard build failure.
Restating costs nothing: same coordinate, same inherited property, so the plugin
and the platform still cannot drift apart. -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-bom</artifactId>
<version>${version.quarkus}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>de.cuioss</groupId>
<artifactId>java-ee-orthogonal</artifactId>
<version>${version.cui.parent}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>de.cuioss</groupId>
<artifactId>java-ee-10-bom</artifactId>
<version>${version.cui.parent}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- Token Sheriff BOM: supplies token-sheriff-client / -client-quarkus / -validation-quarkus
versions. Declared after quarkus-bom on purpose: quarkus-bom is imported first, so it wins
every artifact the two BOMs both manage. Re-measured against the resolved dependency graph
at token-sheriff 0.9.5 / Quarkus 3.39.3 (cui-quarkus-parent 1.7.4): the two Quarkus lines
have DIVERGED. token-sheriff 0.9.5 was built against 3.39.2 - its parent sits on
cui-quarkus-parent 1.7.3 - while this project inherits 3.39.3. The resolved graph lands
token-sheriff's Quarkus artifacts (quarkus-config-yaml, quarkus-hibernate-validator) on
3.39.3, this project's line, and io.smallrye.config still converges on a single 3.17.2
across the whole reactor at compile scope, because both Quarkus patches expect that same
smallrye-config release.
The lines agreed while both parents matched, and now differ by one patch; that is the
normal state between a cui-quarkus-parent bump here and the next token-sheriff release,
not an exception. Keep the ordering: it is what keeps ONE Quarkus line in the build, and a
second line entering it can split smallrye-config, which breaks Quarkus config-mapping
augmentation. Today the split is avoided twice over - the ordering, and the two patches
expecting the same smallrye-config - and only the first of those is under this
project's control.
Re-measure this paragraph on every ${version.token-sheriff} bump. The numbers above are an
observation of ONE resolved graph, not a standing invariant: the upstream Quarkus line moves
independently of ours, so a stale paragraph would keep asserting a convergence nobody has
checked. Measure with
`dependency:tree -pl api-sheriff -Dincludes=io.smallrye.config:*,io.quarkus:quarkus-config-yaml,io.quarkus:quarkus-hibernate-validator`
and read the upstream-declared version off token-sheriff-parent's version.quarkus. -->
<dependency>
<groupId>de.cuioss.sheriff.token</groupId>
<artifactId>token-sheriff-bom</artifactId>
<version>${version.token-sheriff}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- Configuration management: boot-time JSON Schema validation
(jackson-dataformat-yaml version is managed by the Quarkus BOM) -->
<dependency>
<groupId>com.networknt</groupId>
<artifactId>json-schema-validator</artifactId>
<version>${version.json-schema-validator}</version>
</dependency>
<!-- Internal modules -->
<dependency>
<groupId>de.cuioss.sheriff.gateway</groupId>
<artifactId>api-sheriff</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<!-- <release> is NOT set here: it comes from maven.compiler-plugin.release above. -->
<showDeprecation>true</showDeprecation>
<!--
showDeprecation alone only PRINTS the warning, and a printed warning is
not a signal anything acts on: it scrolls past in CI and never reaches
the build executor's error payload. failOnWarning is what converts it
into a build failure carrying the file and line, so a newly deprecated
API cannot re-accumulate silently. Reactor-wide by virtue of living in
pluginManagement — all six modules inherit it.
The flag is only affordable because every deprecation site was retired
by MIGRATION, not by suppression: a clean whole-reactor test-compile is
deprecation-free and this plan introduced no @SuppressWarnings.
Answering a future warning with a suppression rather than a fix would
hollow the gate out while leaving it green.
-->
<failOnWarning>true</failOnWarning>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<java.util.logging.config.file>${project.build.testOutputDirectory}/logging.properties</java.util.logging.config.file>
<maven.home>${maven.home}</maven.home>
<quarkus.test.arg-line>@{argLine}</quarkus.test.arg-line>
</systemPropertyVariables>
<useModulePath>false</useModulePath>
<useFile>false</useFile>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
<!-- JaCoCo-compatible argLine (will be empty if JaCoCo not active) -->
<argLine>@{argLine} -XX:+IgnoreUnrecognizedVMOptions -Djava.awt.headless=true</argLine>
<!-- Stability configurations -->
<forkedProcessTimeoutInSeconds>0</forkedProcessTimeoutInSeconds>
<forkedProcessExitTimeoutInSeconds>60</forkedProcessExitTimeoutInSeconds>
<!-- Fix for class loading issues -->
<useSystemClassLoader>false</useSystemClassLoader>
<reuseForks>false</reuseForks>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<java.util.logging.config.file>${project.build.testOutputDirectory}/logging.properties</java.util.logging.config.file>
<maven.home>${maven.home}</maven.home>
<quarkus.test.arg-line>@{argLine}</quarkus.test.arg-line>
</systemPropertyVariables>
<useModulePath>false</useModulePath>
<useFile>false</useFile>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
<argLine>@{argLine} -XX:+IgnoreUnrecognizedVMOptions -Djava.awt.headless=true</argLine>
<!-- Fix for class loading issues -->
<useSystemClassLoader>false</useSystemClassLoader>
<reuseForks>false</reuseForks>
<!-- Standardized IT naming patterns -->
<includes>
<include>**/*IT.java</include>
<include>**/*IntegrationTest.java</include>
</includes>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
<profiles>
<profile>
<id>coverage</id>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<append>true</append>
<destFile>${project.build.directory}/jacoco.exec</destFile>
</configuration>
</execution>
<execution>
<id>prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<destFile>${project.build.directory}/jacoco-it.exec</destFile>
<append>true</append>
</configuration>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/site/jacoco</outputDirectory>
<formats>
<format>XML</format>
<format>HTML</format>
</formats>
</configuration>
</execution>
<execution>
<id>report-integration</id>
<phase>post-integration-test</phase>
<goals>
<goal>report-integration</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/site/jacoco-it</outputDirectory>
<formats>
<format>XML</format>
<format>HTML</format>
</formats>
</configuration>
</execution>
<execution>
<id>merge-results</id>
<phase>verify</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<fileSets>
<fileSet>
<directory>${project.build.directory}</directory>
<includes>
<include>*.exec</include>
</includes>
</fileSet>
</fileSets>
<destFile>${project.build.directory}/jacoco-merged.exec</destFile>
</configuration>
</execution>
<execution>
<id>report-merged</id>
<phase>verify</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>${project.build.directory}/jacoco-merged.exec</dataFile>
<outputDirectory>${project.build.directory}/site/jacoco-merged</outputDirectory>
<formats>
<format>XML</format>
<format>HTML</format>
</formats>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<properties>
<sonar.coverage.jacoco.xmlReportPaths>
${project.build.directory}/site/jacoco/jacoco.xml,
api-sheriff/target/site/jacoco/jacoco.xml,
../target/site/jacoco/jacoco.xml
</sonar.coverage.jacoco.xmlReportPaths>
</properties>
</profile>
<profile>
<!--
Local override of the inherited cui-java-parent 'pre-commit' profile's
OpenRewrite recipe list.
The parent (de.cuioss:cui-java-parent) activates the recipe
'org.openrewrite.java.migrate.UpgradeToJava21' — a Java-21-TARGETED
migration. On this Java 25 project (ADR-0001) its build-config migration
rewrites the maven-compiler-plugin release DOWN from 25 to 21, silently
regressing the language baseline and breaking any Java 22+ source once
committed.
Maven merges an inherited <activeRecipes> list by APPEND, so a single
recipe cannot be removed in isolation. This re-declares the full list
with combine.children="override".
The list is cui-java-parent's, MINUS the whole
org.openrewrite.java.migrate.* upgrade composite. An earlier revision of
this block instead swapped UpgradeToJava21 for UpgradeToJava25 and claimed
the list was otherwise identical to the parent's. Both halves of that claim
were wrong: UpgradeToJava25 CONTAINS UpgradeToJava21 (so the swap removed
nothing), and the list had also re-enabled JavaUtilAPIs, which the parent
deliberately excludes as broken. See the per-recipe comments below for the
measured failure each exclusion prevents.
Consequence accepted deliberately: the one-time modernization migrations
(UseTextBlocks, InstanceOfPatternMatch, SwitchExpressions,
SequencedCollection, …) no longer run. On a codebase authored at Java 25
they are near-no-ops, and they are not worth a formatter that can emit
source which does not parse. Keep this list in sync if the parent's recipe
set changes.
-->
<id>pre-commit</id>
<build>
<plugins>
<plugin>
<groupId>org.openrewrite.maven</groupId>
<artifactId>rewrite-maven-plugin</artifactId>
<configuration>
<activeRecipes combine.children="override">
<recipe>org.openrewrite.java.format.AutoFormat</recipe>
<recipe>org.openrewrite.java.format.NormalizeLineBreaks</recipe>
<recipe>org.openrewrite.java.format.RemoveTrailingWhitespace</recipe>
<recipe>de.cuioss.rewrite.format.AnnotationNewlineFormat</recipe>
<recipe>de.cuioss.rewrite.logging.CuiLoggerStandardsRecipe</recipe>
<recipe>de.cuioss.rewrite.logging.CuiLogRecordPatternRecipe</recipe>
<recipe>de.cuioss.rewrite.logging.InvalidExceptionUsageRecipe</recipe>
<!--
UpgradeToJava25 intentionally excluded (was: replacing the parent's
UpgradeToJava21). Two measured reasons:
1. It does NOT avoid UpgradeToJava21 — it CONTAINS it. The chain is
UpgradeToJava25 -> UpgradeToJava21 -> UpgradeToJava17 -> Java8toJava11,
verified in rewrite-migrate-java's java-version-{25,21,17,11}.yml. So the
swap this entry used to perform never removed the Java-21 build-config
migration it was written to remove; both ran.
2. That chain reaches org.openrewrite.java.migrate.lang.RenameUnderscoreIdentifier,
whose own metadata reads "Renames single-underscore identifiers to
double-underscore in Java source files with source compatibility of Java 8 or
below. In Java 9+, `_` is a reserved keyword". Since Java 22 `_` is legal again
as an UNNAMED VARIABLE, which this codebase uses widely. Running the gate
rewrote `catch (UrlSecurityException _)` to `catch (UrlSecurityException )`
across ~180 files, i.e. into source that does not parse, and the build then
failed with a wall of "<ID> expected". See lesson 2026-09-01-19-001.
A Java-8-to-25 migration composite has nothing legitimate to do on a codebase
already written at Java 25 (ADR-0001); it can only damage it. OpenRewrite offers
no per-sub-recipe exclusion, so — following the precedent the parent set for
JavaUtilAPIs below — the whole composite is dropped rather than patched.
-->
<recipe>org.openrewrite.java.migrate.RemoveSecurityManager</recipe>
<!--
JavaUtilAPIs intentionally excluded, restoring the parent's own exclusion.
cui-java-parent 1.5.10 comments this recipe out because its transitive UseMapOf
produces "broken, non-compiling output" (see TokenSheriff PR #577). The override
block below silently re-enabled it while its header claimed the list was
"identical to cui-java-parent's list, except UpgradeToJava21 is replaced by
UpgradeToJava25" — it was not. Re-enabling a recipe the parent had deliberately
removed as broken was never an intended part of that swap.
-->
<recipe>org.openrewrite.java.OrderImports</recipe>
<recipe>org.openrewrite.java.RemoveUnusedImports</recipe>
<recipe>org.openrewrite.java.ShortenFullyQualifiedTypeReferences</recipe>
<recipe>org.openrewrite.java.testing.junit5.JUnit5BestPractices</recipe>
<recipe>org.openrewrite.java.testing.junit5.RemoveTryCatchFailBlocks</recipe>
<recipe>org.openrewrite.staticanalysis.EqualsAvoidsNull</recipe>
<recipe>org.openrewrite.staticanalysis.NoPrimitiveWrappersForToStringOrCompareTo</recipe>
<recipe>org.openrewrite.staticanalysis.SimplifyBooleanExpression</recipe>
<recipe>org.openrewrite.staticanalysis.UnnecessaryParentheses</recipe>
</activeRecipes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>