Große Sammlung Maven allgemein

203 konkrete Einträge zu POM, Dependencies, Multi-Module, Lifecycle, Profilen, Settings, Toolchains, Ressourcen, CI/CD, Security und Supply Chain - jeweils mit Konfigurationsbeispiel.

POMBOMReactorsettings.xmlCI/CDSecurity
Maven Allgemein Wissenskarte
01. Projektstruktur und POM-Basics 12 Einträge

mvn001: Projektkoordinaten eindeutig setzen

Englischer technischer Begriff: Project Coordinates / GAV
Priorität: 10/10
Warum wichtig: groupId, artifactId und version sind die Identitaet eines Artefakts in Repository, CI und Dependency-Graph.
Typischer Fehler: Unklare groupId wie `test` oder `demo` macht Artefakte spaeter schwer auffindbar und kollidiert in internen Repositories.
Enterprise-Einordnung: Grundlage fuer alle Enterprise Builds, Releases und Audits.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>order-service</artifactId>
  <version>1.12.0</version>
  <packaging>jar</packaging>
</project>

mvn002: Parent-POM sauber referenzieren

Englischer technischer Begriff: Parent POM Reference
Priorität: 10/10
Warum wichtig: Ein Parent-POM zentralisiert Build-Regeln, Plugin-Versionen und Dependency-Management.
Typischer Fehler: Jedes Modul kopiert eigene Versionen und driftet nach wenigen Sprints auseinander.
Enterprise-Einordnung: Wichtig fuer mehrere Teams und einheitliche Governance.
Konfigurationsbeispiel
<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>com.acme.platform</groupId>
    <artifactId>enterprise-parent</artifactId>
    <version>1.12.0</version>
  </parent>
  <artifactId>order-service</artifactId>
  <packaging>jar</packaging>
</project>

mvn003: Aggregator-POM vom Parent-POM unterscheiden

Englischer technischer Begriff: Aggregator vs Parent POM
Priorität: 9/10
Warum wichtig: Ein Aggregator steuert den Reactor; ein Parent vererbt Konfiguration. Beides kann, muss aber nicht dieselbe Datei sein.
Typischer Fehler: Builds schlagen unvorhersehbar fehl, weil Module nur aggregiert, aber nicht vom gleichen Parent erben.
Enterprise-Einordnung: Hilft bei grossen Monorepos mit fachlichen Modulen.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>commerce-reactor</artifactId>
  <version>1.12.0</version>
  <packaging>pom</packaging>
  <modules>
    <module>parent</module>
    <module>services/order-service</module>
    <module>services/billing-service</module>
  </modules>
</project>

mvn004: Packaging bewusst festlegen

Englischer technischer Begriff: Packaging Type
Priorität: 9/10
Warum wichtig: Packaging bestimmt Lifecycle, Artefakttyp und welche Standardziele Maven ausfuehrt.
Typischer Fehler: Ein Parent wird versehentlich als `jar` gepackt oder ein Service-POM bleibt ohne klares Packaging.
Enterprise-Einordnung: Relevant fuer Jar, War, Ear, Pom, Test-Jar und BOMs.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>enterprise-parent</artifactId>
  <version>1.12.0</version>
  <packaging>pom</packaging>
</project>

mvn005: Metadaten fuer Repository und Audit pflegen

Englischer technischer Begriff: Project Metadata
Priorität: 7/10
Warum wichtig: Beschreibung, URL, Organisation und Lizenz helfen bei Repository-Suche und Compliance.
Typischer Fehler: Artefakte erscheinen im Nexus/Artifactory ohne Kontext und muessen manuell nachrecherchiert werden.
Enterprise-Einordnung: Wichtig fuer interne Plattformteams und Lizenzberichte.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>billing-api</artifactId>
  <version>1.12.0</version>
  <name>ACME Billing API</name>
  <description>Public API contract for billing and invoice integration.</description>
  <url>https://git.acme.local/commerce/billing-api</url>
  <organization>
    <name>ACME Commerce Platform</name>
    <url>https://platform.acme.local</url>
  </organization>
</project>

mvn006: SCM-Daten im POM hinterlegen

Englischer technischer Begriff: SCM Metadata
Priorität: 8/10
Warum wichtig: SCM-Metadaten verbinden Artefakte mit Git-Repository und Release-Historie.
Typischer Fehler: Security oder Betrieb findet bei einem Artefakt nicht mehr den Quellcode.
Enterprise-Einordnung: Unterstuetzt Traceability, Release Notes und Incident Analyse.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>invoice-client</artifactId>
  <version>1.12.0</version>
  <scm>
    <connection>scm:git:ssh://git.acme.local/commerce/invoice-client.git</connection>
    <developerConnection>scm:git:ssh://git@git.acme.local/commerce/invoice-client.git</developerConnection>
    <tag>invoice-client-1.12.0</tag>
  </scm>
</project>

mvn007: Issue- und CI-Management dokumentieren

Englischer technischer Begriff: Issue Management / CI Management
Priorität: 6/10
Warum wichtig: POM-Metadaten geben Tools und Menschen Hinweise auf Pipeline und Backlog.
Typischer Fehler: Betriebsteams suchen bei Fehlern manuell nach Job, Repo und Ticketprojekt.
Enterprise-Einordnung: Hilft in regulierten Umgebungen bei Nachvollziehbarkeit.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>customer-service</artifactId>
  <version>1.12.0</version>
  <issueManagement>
    <system>Jira</system>
    <url>https://jira.acme.local/projects/CUST</url>
  </issueManagement>
  <ciManagement>
    <system>GitLab CI</system>
    <url>https://git.acme.local/commerce/customer-service/-/pipelines</url>
  </ciManagement>
</project>

mvn008: Lizenzinformationen konkret eintragen

Englischer technischer Begriff: License Metadata
Priorität: 8/10
Warum wichtig: Lizenzdaten werden von SBOM-, Site- und Repository-Werkzeugen gelesen.
Typischer Fehler: Interne Artefakte haben unklare Nutzungserlaubnis oder externe Artefakte werden falsch bewertet.
Enterprise-Einordnung: Grundlage fuer rechtliche Freigabe und interne Wiederverwendung.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>platform-commons</artifactId>
  <version>1.12.0</version>
  <licenses>
    <license>
      <name>ACME Internal Use Only</name>
      <url>https://legal.acme.local/licenses/internal-use</url>
      <distribution>repo</distribution>
    </license>
  </licenses>
</project>

mvn009: Relative Parent-Pfade bewusst steuern

Englischer technischer Begriff: Parent Relative Path
Priorität: 8/10
Warum wichtig: relativePath entscheidet, ob Maven zuerst lokal im Dateisystem oder aus dem Repository aufloest.
Typischer Fehler: Ein Release-Build verwendet versehentlich einen lokalen Parent aus dem Checkout.
Enterprise-Einordnung: Wichtig fuer saubere CI-Builds und externe Modul-Releases.
Konfigurationsbeispiel
<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>com.acme.platform</groupId>
    <artifactId>enterprise-parent</artifactId>
    <version>1.12.0</version>
    <relativePath/> <!-- Parent nur aus Repository aufloesen -->
  </parent>
  <artifactId>standalone-partner-client</artifactId>
  <packaging>jar</packaging>
</project>

mvn010: Namen konsistent zu Artefakten halten

Englischer technischer Begriff: Artifact Naming Convention
Priorität: 7/10
Warum wichtig: Konsequente Namen vereinfachen Repository-Navigation und Modulzuordnung.
Typischer Fehler: Ein Modul heisst `core`, das Artefakt `common2` und der Service im Betrieb `partner-sync`.
Enterprise-Einordnung: Skaliert besser fuer viele Services und Plattformmodule.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce.partner</groupId>
  <artifactId>partner-sync-service</artifactId>
  <version>2.4.0</version>
  <name>Partner Sync Service</name>
  <description>Synchronizes partner catalog and contract data.</description>
</project>

mvn011: Versionen nicht in Artefaktnamen codieren

Englischer technischer Begriff: Version in GAV only
Priorität: 8/10
Warum wichtig: Die Version gehoert in das version-Feld, nicht in artifactId oder Modulnamen.
Typischer Fehler: Artefakte wie `order-service-v2` bleiben technisch ewig v2 und verwirren Releases.
Enterprise-Einordnung: Erleichtert automatische Updates und Dependency-Analyse.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>order-service</artifactId>
  <version>2.0.0</version>
  <packaging>jar</packaging>
</project>

mvn012: BOM-Projekte als pom verpacken

Englischer technischer Begriff: BOM Packaging
Priorität: 9/10
Warum wichtig: Eine BOM ist ein POM-Artefakt und enthaelt nur dependencyManagement.
Typischer Fehler: BOM wird als jar gebaut und erzeugt nutzlose Artefakte.
Enterprise-Einordnung: Zentraler Baustein fuer Plattform-Versionierung.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>acme-commerce-bom</artifactId>
  <version>2026.07</version>
  <packaging>pom</packaging>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.acme.commerce</groupId>
        <artifactId>billing-api</artifactId>
        <version>1.12.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>
02. Parent-POM und Build-Governance 12 Einträge

mvn013: Java-Version zentral definieren

Englischer technischer Begriff: Central Java Release Property
Priorität: 10/10
Warum wichtig: Eine zentrale Release-Property verhindert gemischte Bytecode-Ziele.
Typischer Fehler: Module setzen Java 17, 21 und 22 durcheinander.
Enterprise-Einordnung: Wichtig fuer Runtime-Kompatibilitaet auf Servern und Containern.
Konfigurationsbeispiel
<properties>
  <maven.compiler.release>21</maven.compiler.release>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

mvn014: Plugin-Versionen nur in pluginManagement fixieren

Englischer technischer Begriff: Plugin Management Governance
Priorität: 10/10
Warum wichtig: pluginManagement pinnt Versionen, ohne jedes Plugin sofort auszufuehren.
Typischer Fehler: Plugins werden in jedem Modul mit anderer Version deklariert.
Enterprise-Einordnung: Standard fuer grosse Multi-Module-Builds.
Konfigurationsbeispiel
<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${maven.compiler.plugin.version}</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

mvn015: Dependency-Versionen nur in dependencyManagement halten

Englischer technischer Begriff: Dependency Management Governance
Priorität: 10/10
Warum wichtig: dependencyManagement steuert Versionen zentral; Module deklarieren nur den Bedarf.
Typischer Fehler: Jedes Modul nennt eigene Spring-, Jackson- oder Jakarta-Versionen.
Enterprise-Einordnung: Reduziert CVE-Update-Aufwand und Konflikte.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>${jackson.bom.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn016: Build-Defaults mit properties lesbar halten

Englischer technischer Begriff: Build Properties
Priorität: 8/10
Warum wichtig: Properties machen POMs wartbarer als mehrfach kopierte Werte.
Typischer Fehler: Gleicher Wert steht an zehn Stellen und wird unvollstaendig aktualisiert.
Enterprise-Einordnung: Sinnvoll fuer Environments, Encoding, Java-Versionen und Plugin-Versionen.
Konfigurationsbeispiel
<properties>
  <acme.platform.version>1.12.0</acme.platform.version>
  <surefire.failIfNoSpecifiedTests>false</surefire.failIfNoSpecifiedTests>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

mvn017: Konventionen durch Enforcer-Regeln absichern

Englischer technischer Begriff: Build Rule Enforcement
Priorität: 9/10
Warum wichtig: Regeln stoppen Builds frueh, bevor falsche Maven- oder Java-Versionen Artefakte erzeugen.
Typischer Fehler: Der Build funktioniert lokal, bricht aber in CI oder Produktion ab.
Enterprise-Einordnung: Erhoeht Reproduzierbarkeit und senkt Betriebsschäden.
Konfigurationsbeispiel
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-enforcer-plugin</artifactId>
      <executions>
        <execution>
          <id>enforce-build-baseline</id>
          <goals><goal>enforce</goal></goals>
          <configuration>
            <rules>
              <requireJavaVersion><version>[21,)</version></requireJavaVersion>
              <requireMavenVersion><version>[3.9,)</version></requireMavenVersion>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

mvn018: Gemeinsame Testkonfiguration zentral halten

Englischer technischer Begriff: Central Test Configuration
Priorität: 8/10
Warum wichtig: Test-Defaults gehoeren in den Parent, Modul-spezifische Abweichungen in Module.
Typischer Fehler: Jedes Modul hat andere Includes, Forks und Timeouts.
Enterprise-Einordnung: Vereinheitlicht CI-Laufzeiten und Fehleranalyse.
Konfigurationsbeispiel
<properties>
  <argLine>-Duser.timezone=UTC -Dfile.encoding=UTF-8</argLine>
  <surefire.forkCount>1</surefire.forkCount>
  <surefire.reuseForks>true</surefire.reuseForks>
</properties>

mvn019: Enterprise-Repositories nicht in jedem Modul duplizieren

Englischer technischer Begriff: Repository Governance
Priorität: 8/10
Warum wichtig: Repository-Definitionen gehoeren zentral oder besser in settings.xml.
Typischer Fehler: Jedes Team traegt eigene Repository-URLs ein.
Enterprise-Einordnung: Senkt Risiko fuer falsche Snapshot-/Release-Quellen.
Konfigurationsbeispiel
<repositories>
  <repository>
    <id>acme-releases</id>
    <url>https://repo.acme.local/maven/releases</url>
    <releases><enabled>true</enabled></releases>
    <snapshots><enabled>false</enabled></snapshots>
  </repository>
</repositories>

mvn020: Reporting getrennt vom Build halten

Englischer technischer Begriff: Reporting vs Build
Priorität: 6/10
Warum wichtig: Reporting ist fuer Site/Reports; Build-Plugins gehoeren in build/plugins.
Typischer Fehler: Ein Analyse-Plugin wird nur im reporting eingetragen und laeuft nie in CI.
Enterprise-Einordnung: Wichtig fuer klare CI Quality Gates.
Konfigurationsbeispiel
<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-project-info-reports-plugin</artifactId>
    </plugin>
  </plugins>
</reporting>

mvn021: Unternehmensweite Distribution zentralisieren

Englischer technischer Begriff: Central Distribution Management
Priorität: 9/10
Warum wichtig: distributionManagement bestimmt wohin Releases und Snapshots deployed werden.
Typischer Fehler: Module deployen in unterschiedliche Repositories.
Enterprise-Einordnung: Notwendig fuer kontrollierte Artefaktverteilung.
Konfigurationsbeispiel
<distributionManagement>
  <repository>
    <id>acme-releases</id>
    <url>https://repo.acme.local/maven/releases</url>
  </repository>
  <snapshotRepository>
    <id>acme-snapshots</id>
    <url>https://repo.acme.local/maven/snapshots</url>
  </snapshotRepository>
</distributionManagement>

mvn022: Parent nicht mit fachlichen Dependencies ueberladen

Englischer technischer Begriff: Lean Parent POM
Priorität: 8/10
Warum wichtig: Ein Parent soll Versionen und Build-Regeln liefern, nicht automatisch fachliche Libraries in jedes Modul ziehen.
Typischer Fehler: Alle Module bekommen Web-, DB- und Messaging-Libs, obwohl sie sie nicht brauchen.
Enterprise-Einordnung: Reduziert Angriffsfläche und Dependency-Bloat.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.postgresql</groupId>
      <artifactId>postgresql</artifactId>
      <version>${postgresql.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>
<!-- Keine direkte <dependencies>-Deklaration fuer Datenbanktreiber im Parent. -->

mvn023: Build-Zeitstempel reproduzierbar setzen

Englischer technischer Begriff: Output Timestamp Governance
Priorität: 8/10
Warum wichtig: outputTimestamp stabilisiert Jar-/War-Inhalte fuer reproduzierbare Builds.
Typischer Fehler: Zwei Builds mit gleichem Source erzeugen unterschiedliche Checksums.
Enterprise-Einordnung: Hilft bei Supply-Chain-Pruefung und Artefaktvergleich.
Konfigurationsbeispiel
<properties>
  <project.build.outputTimestamp>2026-07-07T00:00:00Z</project.build.outputTimestamp>
</properties>

mvn024: Moduluebergreifende Skip-Flags standardisieren

Englischer technischer Begriff: Build Toggle Properties
Priorität: 7/10
Warum wichtig: Einheitliche Flags machen CI-Matrix und lokale Builds kontrollierbar.
Typischer Fehler: Jedes Modul nutzt eigene Flags wie skipIT, skipIts, skip.integration.
Enterprise-Einordnung: Wichtig fuer schnelle, aber nachvollziehbare Pipeline-Varianten.
Konfigurationsbeispiel
<properties>
  <skip.unit.tests>false</skip.unit.tests>
  <skip.integration.tests>false</skip.integration.tests>
  <skip.security.scan>false</skip.security.scan>
</properties>
03. Dependency-Management und BOMs 16 Einträge

mvn025: BOM importieren statt Einzelversionen pflegen

Englischer technischer Begriff: BOM Import
Priorität: 10/10
Warum wichtig: Eine BOM synchronisiert kompatible Versionen einer Plattform.
Typischer Fehler: Einzelne Spring- oder Jackson-Module landen in inkompatiblen Versionen.
Enterprise-Einordnung: Zentral fuer Spring Boot, Quarkus, Jakarta und interne Plattform-BOMs.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.acme.platform</groupId>
      <artifactId>acme-commerce-bom</artifactId>
      <version>2026.07</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn026: Modul-Dependencies ohne Version deklarieren

Englischer technischer Begriff: Managed Dependency Declaration
Priorität: 9/10
Warum wichtig: Wenn Versionen aus dependencyManagement kommen, bleiben Modul-POMs schlank.
Typischer Fehler: Module ueberschreiben zentrale Versionen unbemerkt.
Enterprise-Einordnung: Vereinfacht Updates in grossen Reactor-Builds.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.commerce</groupId>
    <artifactId>billing-api</artifactId>
  </dependency>
</dependencies>

mvn027: Eigene API-Artefakte zentral versionieren

Englischer technischer Begriff: Internal API Version Management
Priorität: 9/10
Warum wichtig: Interne API-Artefakte gehoeren in die Unternehmens-BOM.
Typischer Fehler: Services referenzieren beliebige API-Versionen.
Enterprise-Einordnung: Wichtig fuer Service-Kompatibilitaet und Contract Governance.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.acme.contracts</groupId>
      <artifactId>partner-contract-api</artifactId>
      <version>4.3.0</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn028: Transitive Versionen nicht blind akzeptieren

Englischer technischer Begriff: Transitive Dependency Control
Priorität: 9/10
Warum wichtig: Transitive Dependencies koennen unerwartete Versionen einschleppen.
Typischer Fehler: Ein altes Framework zieht eine verwundbare Logging-Library mit.
Enterprise-Einordnung: Relevant fuer CVE-Reaktion und stabile Produktion.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>2.0.13</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn029: Mehrere BOMs bewusst ordnen

Englischer technischer Begriff: BOM Precedence
Priorität: 8/10
Warum wichtig: Bei mehreren BOMs entscheidet die Reihenfolge ueber wirksame Versionen.
Typischer Fehler: Eine interne BOM wird vor der Plattform-BOM importiert und greift nicht.
Enterprise-Einordnung: Wichtig bei Hersteller-BOM plus Unternehmens-BOM.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>${spring.boot.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    <dependency>
      <groupId>com.acme.platform</groupId>
      <artifactId>acme-overrides-bom</artifactId>
      <version>2026.07</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn030: Classifier-Artefakte versionieren

Englischer technischer Begriff: Classifier Dependency
Priorität: 7/10
Warum wichtig: Classifier trennen Varianten wie tests, native, sources oder schemas.
Typischer Fehler: Teams bauen inoffizielle Zip-Dateien neben Maven vorbei.
Enterprise-Einordnung: Hilfreich fuer Test-Fixtures und generierte Schemata.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.contracts</groupId>
  <artifactId>order-contract</artifactId>
  <version>3.8.0</version>
  <classifier>schemas</classifier>
  <type>zip</type>
</dependency>

mvn031: Optional-Dependencies bewusst einsetzen

Englischer technischer Begriff: Optional Dependency
Priorität: 8/10
Warum wichtig: optional verhindert, dass Implementierungsdetails automatisch transitiv weitergegeben werden.
Typischer Fehler: Eine Library zieht Servlet- oder JDBC-Implementierungen in Consumer.
Enterprise-Einordnung: Wichtig fuer wiederverwendbare Starter und Commons-Module.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.platform</groupId>
  <artifactId>platform-observability-bridge</artifactId>
  <version>1.12.0</version>
  <optional>true</optional>
</dependency>

mvn032: Exclusions gezielt und dokumentiert verwenden

Englischer technischer Begriff: Dependency Exclusion
Priorität: 8/10
Warum wichtig: Exclusions entfernen konkrete transitive Artefakte, sollen aber begruendet sein.
Typischer Fehler: Breite Exclusions entfernen noetige Libraries und brechen zur Laufzeit.
Enterprise-Einordnung: Wichtig bei Legacy-Stacks und Container-provided Libraries.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.legacy</groupId>
  <artifactId>legacy-soap-client</artifactId>
  <version>5.4.2</version>
  <exclusions>
    <exclusion>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
    <exclusion>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
    </exclusion>
  </exclusions>
</dependency>

mvn033: Runtime-Dependency von Compile-API trennen

Englischer technischer Begriff: Compile vs Runtime Dependency
Priorität: 9/10
Warum wichtig: Nur APIs gehoeren in compile; konkrete Treiber oft in runtime.
Typischer Fehler: Datenbanktreiber werden Teil der oeffentlichen API.
Enterprise-Einordnung: Reduziert Kopplung und erleichtert Treiberwechsel.
Konfigurationsbeispiel
<dependency>
  <groupId>org.postgresql</groupId>
  <artifactId>postgresql</artifactId>
  <scope>runtime</scope>
</dependency>

mvn034: Test-Fixtures separat einbinden

Englischer technischer Begriff: Test Fixtures Dependency
Priorität: 7/10
Warum wichtig: Testdaten und Testhelfer gehoeren nicht in Produktionsartefakte.
Typischer Fehler: Fixtures landen im finalen Jar und vergroessern die Runtime.
Enterprise-Einordnung: Wichtig fuer moduluebergreifende Integrationstests.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.testing</groupId>
  <artifactId>commerce-test-fixtures</artifactId>
  <version>1.12.0</version>
  <scope>test</scope>
</dependency>

mvn035: Provided-Scope fuer Container-APIs nutzen

Englischer technischer Begriff: Provided Scope
Priorität: 9/10
Warum wichtig: provided markiert APIs, die der Application Server oder Servlet Container bereitstellt.
Typischer Fehler: Servlet-API wird in WAR mitgeliefert und kollidiert mit dem Container.
Enterprise-Einordnung: Klassisch bei Jakarta EE, Servlet und App-Servern.
Konfigurationsbeispiel
<dependency>
  <groupId>jakarta.servlet</groupId>
  <artifactId>jakarta.servlet-api</artifactId>
  <scope>provided</scope>
</dependency>

mvn036: Import-Scope nur fuer BOMs verwenden

Englischer technischer Begriff: Import Scope
Priorität: 8/10
Warum wichtig: import ist nur fuer POM-Artefakte in dependencyManagement gedacht.
Typischer Fehler: Eine normale Jar-Dependency wird mit import scope deklariert.
Enterprise-Einordnung: Verhindert verwirrende Aufloesungsfehler.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.acme.platform</groupId>
      <artifactId>acme-jakarta-bom</artifactId>
      <version>10.1.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn037: System-Scope vermeiden

Englischer technischer Begriff: Avoid System Scope
Priorität: 10/10
Warum wichtig: system scope ist nicht portabel und bricht CI-Reproduzierbarkeit.
Typischer Fehler: Ein lokales Jar aus C:\libs wird in der CI nicht gefunden.
Enterprise-Einordnung: Enterprise Builds muessen Artefakte ueber Repositories aufloesen.
Konfigurationsbeispiel
<!-- Besser: Drittanbieter-Jar ins interne Repository deployen und normal referenzieren. -->
<dependency>
  <groupId>com.vendor.legacy</groupId>
  <artifactId>payment-terminal-sdk</artifactId>
  <version>2.8.1</version>
</dependency>

mvn038: Dependency-Konflikte mit direkter Dependency klaeren

Englischer technischer Begriff: Nearest Dependency Control
Priorität: 8/10
Warum wichtig: Direkte Dependencies gewinnen gegen transitive Aufloesung und machen Absicht sichtbar.
Typischer Fehler: Ein Konflikt wird zufaellig durch Modulstruktur geloest.
Enterprise-Einordnung: Wichtig bei Incident-Fixes und CVE-Patches.
Konfigurationsbeispiel
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.17.2</version>
</dependency>

mvn039: Testcontainers nur im Test-Scope halten

Englischer technischer Begriff: Test Infrastructure Scope
Priorität: 8/10
Warum wichtig: Test-Infrastruktur darf nicht in Runtime-Artefakte gelangen.
Typischer Fehler: Testcontainers wird in Produktion mitverpackt.
Enterprise-Einordnung: Wichtig fuer schlanke Container Images.
Konfigurationsbeispiel
<dependency>
  <groupId>org.testcontainers</groupId>
  <artifactId>postgresql</artifactId>
  <version>1.20.1</version>
  <scope>test</scope>
</dependency>

mvn040: Annotation Processor getrennt behandeln

Englischer technischer Begriff: Annotation Processor Path
Priorität: 8/10
Warum wichtig: Processor gehoeren in Compiler-Konfiguration oder provided/test, nicht ungeprueft in Runtime.
Typischer Fehler: Lombok oder MapStruct Processor landen als Runtime-Abhaengigkeit.
Enterprise-Einordnung: Verbessert Artefaktklarheit und Build-Sicherheit.
Konfigurationsbeispiel
<build>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <annotationProcessorPaths>
          <path>
            <groupId>org.mapstruct</groupId>
            <artifactId>mapstruct-processor</artifactId>
            <version>${mapstruct.version}</version>
          </path>
        </annotationProcessorPaths>
      </configuration>
    </plugin>
  </plugins>
</build>
04. Dependency-Scopes und Konfliktkontrolle 16 Einträge

mvn041: Compile-Scope nur fuer oeffentliche API nutzen

Englischer technischer Begriff: Compile Scope Hygiene
Priorität: 9/10
Warum wichtig: compile macht Dependencies fuer Consumer transitiv sichtbar.
Typischer Fehler: Implementierungsdetails werden unabsichtlich Teil des API-Vertrags.
Enterprise-Einordnung: Relevant fuer Libraries, Starter und interne SDKs.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.contracts</groupId>
  <artifactId>order-api</artifactId>
</dependency>

mvn042: Runtime-Scope fuer Implementierungen

Englischer technischer Begriff: Runtime Scope
Priorität: 8/10
Warum wichtig: Runtime-Abhaengigkeiten werden erst beim Ausfuehren benoetigt.
Typischer Fehler: Compile-Pfad wird mit Treibern oder Implementierungen ueberladen.
Enterprise-Einordnung: Haelt API sauber und Build schneller.
Konfigurationsbeispiel
<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <scope>runtime</scope>
</dependency>

mvn043: Test-Scope konsequent fuer Testbibliotheken

Englischer technischer Begriff: Test Scope
Priorität: 9/10
Warum wichtig: Test-Scope verhindert, dass Testbibliotheken im Produktivartefakt landen.
Typischer Fehler: JUnit, Mockito oder AssertJ werden transitiv an Consumer weitergereicht.
Enterprise-Einordnung: Wichtig fuer Artefaktgroesse und Security.
Konfigurationsbeispiel
<dependency>
  <groupId>org.junit.jupiter</groupId>
  <artifactId>junit-jupiter</artifactId>
  <version>5.11.0</version>
  <scope>test</scope>
</dependency>

mvn044: Provided bei Application-Server-Libraries

Englischer technischer Begriff: Provided for Server Runtime
Priorität: 9/10
Warum wichtig: Application Server liefern viele APIs selbst.
Typischer Fehler: WAR/EAR enthaelt doppelte API-Jars und startet nicht sauber.
Enterprise-Einordnung: Wichtig fuer Jakarta EE und Migrationen.
Konfigurationsbeispiel
<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>10.0.0</version>
  <scope>provided</scope>
</dependency>

mvn045: Exclusion mit Ersatzdependency kombinieren

Englischer technischer Begriff: Exclude and Replace
Priorität: 8/10
Warum wichtig: Eine Exclusion soll meist durch eine kontrollierte Version ersetzt werden.
Typischer Fehler: Library wird entfernt, aber keine kompatible Alternative deklariert.
Enterprise-Einordnung: Nutzbar bei Logging-Bridges und Legacy-Clients.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.legacy</groupId>
    <artifactId>old-erp-client</artifactId>
    <version>7.2.0</version>
    <exclusions>
      <exclusion>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>${slf4j.version}</version>
  </dependency>
</dependencies>

mvn046: Dependency-Konvergenz im Parent erzwingen

Englischer technischer Begriff: Dependency Convergence
Priorität: 9/10
Warum wichtig: Konvergenz verhindert unterschiedliche Versionen derselben Library im Graph.
Typischer Fehler: Lokal klappt es, produktiv laedt Classloader eine andere Version.
Enterprise-Einordnung: Wichtig fuer grosse Enterprise-Dependency-Graphen.
Konfigurationsbeispiel
<rules>
  <dependencyConvergence/>
</rules>

mvn047: Upper-Bound-Regeln fuer Konflikte nutzen

Englischer technischer Begriff: Require Upper Bound Dependencies
Priorität: 8/10
Warum wichtig: Upper-bound prueft, ob eine niedrigere transitive Version eine hoehere ueberschreibt.
Typischer Fehler: Eine alte transitive Library gewinnt gegen eine neuere Sicherheitsversion.
Enterprise-Einordnung: Hilft bei CVE-Fixes.
Konfigurationsbeispiel
<rules>
  <requireUpperBoundDeps>
    <excludes>
      <exclude>com.acme.legacy:legacy-all</exclude>
    </excludes>
  </requireUpperBoundDeps>
</rules>

mvn048: Dependency-Analyse in CI laufen lassen

Englischer technischer Begriff: Dependency Analysis
Priorität: 7/10
Warum wichtig: Analyse findet ungenutzte oder nicht deklarierte Dependencies.
Typischer Fehler: Code kompiliert nur wegen transitiver Zufallsdependency.
Enterprise-Einordnung: Verbessert Modulgrenzen und Wartbarkeit.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>analyze-dependencies</id>
      <phase>verify</phase>
      <goals><goal>analyze-only</goal></goals>
      <configuration>
        <failOnWarning>true</failOnWarning>
      </configuration>
    </execution>
  </executions>
</plugin>

mvn049: Dependency-Tree fuer Konfliktanalyse speichern

Englischer technischer Begriff: Dependency Tree Evidence
Priorität: 6/10
Warum wichtig: Ein gespeicherter Dependency Tree hilft bei Reviews und Incidents.
Typischer Fehler: Konflikte werden nur lokal per Terminal angeschaut und nicht dokumentiert.
Enterprise-Einordnung: Nuetzlich fuer Release-Freigaben.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
  <configuration>
    <outputFile>${project.build.directory}/dependency-tree.txt</outputFile>
    <appendOutput>false</appendOutput>
  </configuration>
</plugin>

mvn050: Banned Dependencies fuer Altlasten setzen

Englischer technischer Begriff: Banned Dependencies
Priorität: 9/10
Warum wichtig: Verbotene Artefakte stoppen bekannte Altlasten frueh.
Typischer Fehler: Log4j 1.x oder alte XML-Parser tauchen wieder auf.
Enterprise-Einordnung: Wichtig fuer Security Governance.
Konfigurationsbeispiel
<rules>
  <bannedDependencies>
    <searchTransitive>true</searchTransitive>
    <excludes>
      <exclude>log4j:log4j</exclude>
      <exclude>javax.xml.bind:jaxb-api</exclude>
    </excludes>
  </bannedDependencies>
</rules>

mvn051: Dependency-Reduktion nicht blind nutzen

Englischer technischer Begriff: Dependency Reduced POM Awareness
Priorität: 6/10
Warum wichtig: Reduzierte POMs koennen Consumer-Aufloesung beeinflussen.
Typischer Fehler: Shade entfernt Dependencies, die Consumer eigentlich brauchen.
Enterprise-Einordnung: Wichtig bei Fat Jars und SDKs.
Konfigurationsbeispiel
<configuration>
  <createDependencyReducedPom>true</createDependencyReducedPom>
  <dependencyReducedPomLocation>${project.build.directory}/dependency-reduced-pom.xml</dependencyReducedPomLocation>
</configuration>

mvn052: Keine SNAPSHOT-Dependencies in Releases

Englischer technischer Begriff: No Snapshots in Release
Priorität: 10/10
Warum wichtig: Release-Artefakte muessen auf stabilen Versionen basieren.
Typischer Fehler: Ein Release haengt von 2.0.0-SNAPSHOT ab und ist nicht reproduzierbar.
Enterprise-Einordnung: Pflicht fuer Enterprise Releases.
Konfigurationsbeispiel
<rules>
  <requireReleaseDeps>
    <message>Release builds must not use SNAPSHOT dependencies.</message>
  </requireReleaseDeps>
</rules>

mvn053: Version Ranges nur in Ausnahmefaellen

Englischer technischer Begriff: Avoid Version Ranges
Priorität: 8/10
Warum wichtig: Version Ranges machen Builds zeitabhaengig und schwer reproduzierbar.
Typischer Fehler: Heute wird 1.4.1 gebaut, morgen automatisch 1.5.0.
Enterprise-Einordnung: Reproduzierbarkeit ist wichtiger als automatische Magie.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.contracts</groupId>
  <artifactId>invoice-api</artifactId>
  <version>2.6.3</version>
</dependency>
<!-- Keine Range wie [2.0,3.0) fuer produktive Releases. -->

mvn054: Transitive Optionalitaet nicht erwarten

Englischer technischer Begriff: Optional Transitivity Awareness
Priorität: 7/10
Warum wichtig: optional wirkt nur auf Consumer-Aufloesung und ersetzt keine Modularchitektur.
Typischer Fehler: Man glaubt, eine optional Dependency sei im eigenen Runtime-Pfad nie vorhanden.
Enterprise-Einordnung: Wichtig fuer Starter und technische Libraries.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.platform</groupId>
  <artifactId>platform-metrics-bridge</artifactId>
  <version>1.12.0</version>
  <optional>true</optional>
</dependency>

mvn055: Dependency-Gruppen fachlich schneiden

Englischer technischer Begriff: Dependency Boundary
Priorität: 7/10
Warum wichtig: Fachliche Module sollten nur die benoetigten APIs importieren.
Typischer Fehler: Ein Service haengt von `platform-all` ab und kennt zu viel.
Enterprise-Einordnung: Unterstuetzt modulare Architektur.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.commerce</groupId>
    <artifactId>order-domain-api</artifactId>
  </dependency>
  <dependency>
    <groupId>com.acme.platform</groupId>
    <artifactId>platform-observability-api</artifactId>
  </dependency>
</dependencies>

mvn056: Classifier fuer Test-Jars bewusst behandeln

Englischer technischer Begriff: Test Jar Classifier
Priorität: 6/10
Warum wichtig: Test-Jars koennen gemeinsame Testbasen liefern, sollten aber nicht Runtime werden.
Typischer Fehler: Test-Helper gelangen in Produktionsklassenpfad.
Enterprise-Einordnung: Nuetzlich fuer contract tests und Fixture Libraries.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.testing</groupId>
  <artifactId>payment-contract-tests</artifactId>
  <version>1.12.0</version>
  <classifier>tests</classifier>
  <scope>test</scope>
</dependency>
05. Multi-Module, Reactor und Modulgrenzen 14 Einträge

mvn057: Module im Aggregator explizit ordnen

Englischer technischer Begriff: Explicit Module List
Priorität: 9/10
Warum wichtig: Die Reihenfolge hilft Menschen; Maven berechnet die technische Build-Reihenfolge anhand Dependencies.
Typischer Fehler: Neue Module werden vergessen und CI baut unvollstaendig.
Enterprise-Einordnung: Wichtig fuer Monorepo-Strukturen.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>commerce-reactor</artifactId>
  <version>1.12.0</version>
  <packaging>pom</packaging>
  <modules>
    <module>platform-bom</module>
    <module>order-domain</module>
    <module>order-service</module>
    <module>billing-service</module>
  </modules>
</project>

mvn058: Fachliche Modulgrenzen mit APIs ausdruecken

Englischer technischer Begriff: Module Boundary via API Module
Priorität: 9/10
Warum wichtig: API-Module entkoppeln Verbraucher von Implementierungen.
Typischer Fehler: Ein Service nutzt Klassen aus dem impl-Modul eines anderen Services.
Enterprise-Einordnung: Grundlage fuer interne Contracts.
Konfigurationsbeispiel
<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>com.acme.platform</groupId>
    <artifactId>enterprise-parent</artifactId>
    <version>1.12.0</version>
  </parent>
  <artifactId>billing-api</artifactId>
  <packaging>jar</packaging>
</project>

mvn059: Impl-Modul vom API-Modul abhaengig machen

Englischer technischer Begriff: Implementation Depends on API
Priorität: 8/10
Warum wichtig: Die Implementierung darf das API-Modul kennen, aber nicht umgekehrt.
Typischer Fehler: API enthaelt Repository-, JPA- oder HTTP-Implementierungen.
Enterprise-Einordnung: Verbessert Testbarkeit und Contract-Stabilitaet.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.commerce</groupId>
    <artifactId>billing-api</artifactId>
    <version>${project.version}</version>
  </dependency>
</dependencies>

mvn060: Reactor-Resume fuer grosse Builds nutzen

Englischer technischer Begriff: Reactor Resume
Priorität: 6/10
Warum wichtig: Nach einem Fehler muss nicht der ganze Reactor erneut gebaut werden.
Typischer Fehler: Entwickler starten jedes Mal `mvn clean install` von vorn.
Enterprise-Einordnung: Spart Zeit bei grossen Enterprise-Repos.
Konfigurationsbeispiel
mvn -pl services/order-service -am test
mvn -rf :order-service verify

mvn061: Nur betroffene Module bauen

Englischer technischer Begriff: Selected Reactor Build
Priorität: 8/10
Warum wichtig: -pl und -am bauen gezielt Modul plus benoetigte Abhaengigkeiten.
Typischer Fehler: CI laeuft immer fuer alle Module und wird langsam.
Enterprise-Einordnung: Nuetzlich fuer Pull-Request-Pipelines.
Konfigurationsbeispiel
mvn -pl services/order-service -am verify

mvn062: Abhaengige Module gezielt mitbauen

Englischer technischer Begriff: Also Make Dependents
Priorität: 7/10
Warum wichtig: -amd baut Module, die vom ausgewaehlten Modul abhaengen.
Typischer Fehler: API-Aenderung wird nur lokal kompiliert, Consumer brechen spaeter.
Enterprise-Einordnung: Wichtig bei API-Modulen.
Konfigurationsbeispiel
mvn -pl order-domain-api -amd test

mvn063: Parent separat releasen koennen

Englischer technischer Begriff: Separate Parent Release
Priorität: 7/10
Warum wichtig: Ein stabiler Parent kann von mehreren Repositories genutzt werden.
Typischer Fehler: Jede Service-Version muss den Parent mitreleasen.
Enterprise-Einordnung: Hilft bei Plattform-Governance.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>enterprise-parent</artifactId>
  <version>1.12.0</version>
  <packaging>pom</packaging>
</project>

mvn064: BOM separat vom Aggregator bauen

Englischer technischer Begriff: Separate BOM Module
Priorität: 8/10
Warum wichtig: Die BOM sollte ein klares eigenes Artefakt sein.
Typischer Fehler: Consumer importieren versehentlich den Reactor-Aggregator.
Enterprise-Einordnung: Verhindert unklare Moduleintraege fuer externe Consumer.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.platform</groupId>
  <artifactId>acme-commerce-bom</artifactId>
  <version>2026.07</version>
  <packaging>pom</packaging>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.acme.commerce</groupId>
        <artifactId>order-api</artifactId>
        <version>1.12.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

mvn065: Zyklische Modulabhängigkeiten vermeiden

Englischer technischer Begriff: Avoid Cyclic Module Dependencies
Priorität: 10/10
Warum wichtig: Maven-Reactor und Architektur leiden unter Zyklen.
Typischer Fehler: order-service haengt von billing-service ab und billing-service von order-service.
Enterprise-Einordnung: Zyklen zeigen meist fehlende API- oder Domain-Schnitte.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.commerce</groupId>
    <artifactId>billing-api</artifactId>
    <version>${project.version}</version>
  </dependency>
</dependencies>
<!-- Keine Abhaengigkeit auf billing-service-impl. -->

mvn066: Modulpfade stabil und sprechend halten

Englischer technischer Begriff: Stable Module Paths
Priorität: 6/10
Warum wichtig: Stabile Pfade reduzieren CI- und IDE-Brueche.
Typischer Fehler: Module werden haeufig umbenannt ohne Artefaktstrategie.
Enterprise-Einordnung: Wichtig fuer langlebige Repositories.
Konfigurationsbeispiel
<modules>
  <module>apps/order-service</module>
  <module>libs/order-domain</module>
  <module>contracts/order-events</module>
</modules>

mvn067: Interne Integrationstests als eigenes Modul

Englischer technischer Begriff: IT Module Pattern
Priorität: 8/10
Warum wichtig: Ein eigenes IT-Modul kann mehrere Services/Contracts zusammen testen.
Typischer Fehler: Integrationstests liegen verstreut in Fachmodulen und laufen unkontrolliert.
Enterprise-Einordnung: Nuetzlich fuer komplexe Enterprise-Schnittstellen.
Konfigurationsbeispiel
<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>
  <artifactId>commerce-integration-tests</artifactId>
  <packaging>jar</packaging>
  <dependencies>
    <dependency>
      <groupId>com.acme.commerce</groupId>
      <artifactId>order-service</artifactId>
      <version>${project.version}</version>
      <type>test-jar</type>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

mvn068: Module nicht ueber Parent dependencies koppeln

Englischer technischer Begriff: No Parent Dependency Leakage
Priorität: 9/10
Warum wichtig: Parent dependencies wirken auf alle Kinder und verwischen Modulgrenzen.
Typischer Fehler: Jedes Modul bekommt Datenbank, Web und Messaging automatisch.
Enterprise-Einordnung: Wichtig fuer saubere Architektur.
Konfigurationsbeispiel
<!-- Parent: nur dependencyManagement, keine fachlichen dependencies -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.acme.platform</groupId>
      <artifactId>platform-messaging-api</artifactId>
      <version>1.12.0</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn069: Build-Reihenfolge nicht manuell erzwingen

Englischer technischer Begriff: Reactor Dependency Ordering
Priorität: 6/10
Warum wichtig: Maven sortiert Module nach Abhaengigkeiten, nicht nach modules-Reihenfolge.
Typischer Fehler: Man verschiebt Module in der Liste und glaubt, Abhaengigkeiten seien geloest.
Enterprise-Einordnung: Hilft bei Debugging von Reactor-Problemen.
Konfigurationsbeispiel
<dependencies>
  <dependency>
    <groupId>com.acme.commerce</groupId>
    <artifactId>order-domain</artifactId>
    <version>${project.version}</version>
  </dependency>
</dependencies>

mvn070: Install nur bei Bedarf nutzen

Englischer technischer Begriff: Local Repository Discipline
Priorität: 6/10
Warum wichtig: Bei Reactor-Builds braucht man haeufig kein install, weil Maven Module direkt kennt.
Typischer Fehler: Entwickler verschmutzen lokales Repository mit Zwischenständen.
Enterprise-Einordnung: Sauberere lokale Entwicklung und weniger Phantomfehler.
Konfigurationsbeispiel
mvn -pl apps/order-service -am test
# install erst, wenn ein anderes Repository/Checkout das Artefakt braucht
06. Lifecycle, Phasen und Build-Struktur 12 Einträge

mvn071: Lifecycle-Phasen nicht mit Goals verwechseln

Englischer technischer Begriff: Phase vs Goal
Priorität: 9/10
Warum wichtig: Phasen sind Lifecycle-Schritte; Goals sind Plugin-Aktionen.
Typischer Fehler: Man bindet Goals in falsche Phasen oder ruft zu wenig Lifecycle auf.
Enterprise-Einordnung: Grundwissen fuer stabile Builds.
Konfigurationsbeispiel
mvn clean verify
mvn compiler:compile
mvn dependency:tree

mvn072: verify statt nur package in CI nutzen

Englischer technischer Begriff: Verify Phase
Priorität: 9/10
Warum wichtig: verify fuehrt auch Pruefungen nach package aus, etwa Integrationstests und Checks.
Typischer Fehler: CI baut ein Jar, ohne Tests und Qualitaetsregeln vollstaendig auszufuehren.
Enterprise-Einordnung: Geeignet als Standardziel fuer Pull Requests.
Konfigurationsbeispiel
mvn -B -ntp clean verify

mvn073: clean nicht immer lokal erzwingen

Englischer technischer Begriff: Incremental Build Awareness
Priorität: 6/10
Warum wichtig: clean macht Builds langsamer und verdeckt inkrementelle Probleme.
Typischer Fehler: Jeder lokale Testlauf startet mit clean und kostet Zeit.
Enterprise-Einordnung: Nuetzlich fuer Entwicklerproduktivitaet.
Konfigurationsbeispiel
mvn -pl services/order-service -am test
# clean gezielt bei generierten Quellen oder merkwuerdigem target-Zustand

mvn074: generate-sources fuer generierten Code nutzen

Englischer technischer Begriff: Generated Sources Phase
Priorität: 8/10
Warum wichtig: Generierter Code soll vor compile entstehen und als Source registriert werden.
Typischer Fehler: Generatoren laufen in process-resources und IDEs erkennen Quellen nicht.
Enterprise-Einordnung: Wichtig fuer OpenAPI, JAXB, Protobuf und JPA Metamodel.
Konfigurationsbeispiel
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>build-helper-maven-plugin</artifactId>
      <executions>
        <execution>
          <id>add-generated-api</id>
          <phase>generate-sources</phase>
          <goals><goal>add-source</goal></goals>
          <configuration>
            <sources><source>${project.build.directory}/generated-sources/openapi/src/main/java</source></sources>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

mvn075: process-resources fuer Ressourcenaufbereitung verwenden

Englischer technischer Begriff: Process Resources Phase
Priorität: 7/10
Warum wichtig: Ressourcen werden vor compile vorbereitet und gefiltert.
Typischer Fehler: Konfigurationsdateien werden zur Laufzeit generiert.
Enterprise-Einordnung: Gut fuer Build-Metadaten und Profilwerte.
Konfigurationsbeispiel
<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
      <includes><include>application-build.properties</include></includes>
    </resource>
  </resources>
</build>

mvn076: Integrationstests in passende Phasen legen

Englischer technischer Begriff: Integration Test Lifecycle
Priorität: 9/10
Warum wichtig: pre-integration-test, integration-test und post-integration-test trennen Start, Test und Cleanup.
Typischer Fehler: Container werden gestartet, aber bei Testfehlern nicht sauber beendet.
Enterprise-Einordnung: Wichtig fuer Datenbanken, WireMock und Testcontainers-Umfelder.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-failsafe-plugin</artifactId>
  <executions>
    <execution>
      <id>run-integration-tests</id>
      <goals><goal>integration-test</goal><goal>verify</goal></goals>
    </execution>
  </executions>
</plugin>

mvn077: Package nicht als Deployment missverstehen

Englischer technischer Begriff: Package vs Deploy
Priorität: 8/10
Warum wichtig: package baut lokal, deploy veroeffentlicht in ein Repository.
Typischer Fehler: CI deployt Snapshots aus jedem Branch.
Enterprise-Einordnung: Trennt Build und Artefaktfreigabe.
Konfigurationsbeispiel
mvn clean package
mvn -Prelease deploy

mvn078: Install nicht als Repository-Ersatz nutzen

Englischer technischer Begriff: Install vs Deploy
Priorität: 7/10
Warum wichtig: install schreibt nur ins lokale Maven-Repository.
Typischer Fehler: Teams verteilen Artefakte ueber lokale .m2-Verzeichnisse.
Enterprise-Einordnung: Enterprise braucht Nexus/Artifactory statt lokalen Austausch.
Konfigurationsbeispiel
mvn install
mvn deploy -DaltDeploymentRepository=acme-releases::default::https://repo.acme.local/maven/releases

mvn079: Default Lifecycle fuer Packaging kennen

Englischer technischer Begriff: Packaging Lifecycle Binding
Priorität: 7/10
Warum wichtig: Jar, War und Pom haben unterschiedliche Standardbindungen.
Typischer Fehler: Man erwartet bei packaging pom einen kompilierten Output.
Enterprise-Einordnung: Wichtig fuer Parent, BOM und Aggregator-Projekte.
Konfigurationsbeispiel
<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>
  <artifactId>platform-bom</artifactId>
  <packaging>pom</packaging>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.acme.platform</groupId>
        <artifactId>platform-core</artifactId>
        <version>1.12.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

mvn080: Eigene Executions eindeutig benennen

Englischer technischer Begriff: Execution Id
Priorität: 6/10
Warum wichtig: Execution-IDs helfen beim Debugging und beim Ueberschreiben aus Child-POMs.
Typischer Fehler: Mehrere anonyme Executions sind kaum wartbar.
Enterprise-Einordnung: Wichtig fuer lange Parent-POMs.
Konfigurationsbeispiel
<execution>
  <id>compile-java-21-with-parameters</id>
  <phase>compile</phase>
  <goals><goal>compile</goal></goals>
</execution>

mvn081: Phasenbindungen sparsam halten

Englischer technischer Begriff: Minimal Phase Binding
Priorität: 7/10
Warum wichtig: Nicht jedes Plugin muss an jede Phase gebunden werden.
Typischer Fehler: Builds werden langsam und schwer verstaendlich.
Enterprise-Einordnung: Senkt Wartungskosten in Parent-POMs.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>audit-dependency-tree-on-demand</id>
      <phase>verify</phase>
      <goals><goal>tree</goal></goals>
    </execution>
  </executions>
</plugin>

mvn082: Batch-Modus fuer CI verwenden

Englischer technischer Begriff: Batch Mode
Priorität: 8/10
Warum wichtig: Batch-Modus verhindert interaktive Prompts und reduziert Log-Rauschen.
Typischer Fehler: Pipeline bleibt an einer Nachfrage haengen.
Enterprise-Einordnung: CI-Standard fuer Maven.
Konfigurationsbeispiel
mvn -B -ntp clean verify
07. Properties, Profile und Umgebungen 14 Einträge

mvn083: Properties fuer wiederverwendbare Werte nutzen

Englischer technischer Begriff: Maven Properties
Priorität: 9/10
Warum wichtig: Properties vermeiden harte Wiederholungen in POMs.
Typischer Fehler: Versionen und Pfade werden mehrfach kopiert.
Enterprise-Einordnung: Basis fuer Parent-POMs und CI-Parameter.
Konfigurationsbeispiel
<properties>
  <java.release>21</java.release>
  <acme.environment>dev</acme.environment>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

mvn084: Profile fuer Build-Varianten, nicht fuer Businesslogik

Englischer technischer Begriff: Build Profile
Priorität: 8/10
Warum wichtig: Profile steuern Build-Aspekte, nicht fachliches Verhalten in Produktion.
Typischer Fehler: Produktionslogik haengt davon ab, mit welchem Maven-Profil gebaut wurde.
Enterprise-Einordnung: Enterprise trennt Buildzeit und Laufzeitkonfiguration.
Konfigurationsbeispiel
<profiles>
  <profile>
    <id>ci</id>
    <properties>
      <skip.integration.tests>false</skip.integration.tests>
      <build.environment>ci</build.environment>
    </properties>
  </profile>
</profiles>

mvn085: Profile explizit aktivieren

Englischer technischer Begriff: Explicit Profile Activation
Priorität: 8/10
Warum wichtig: Explizite Aktivierung ist nachvollziehbarer als versteckte Bedingungen.
Typischer Fehler: Build verhaelt sich auf Entwicklerrechner anders als in CI.
Enterprise-Einordnung: Wichtig fuer reproduzierbare Builds.
Konfigurationsbeispiel
mvn -Pci clean verify
mvn -Prelease deploy

mvn086: JDK-Aktivierung nur vorsichtig nutzen

Englischer technischer Begriff: JDK Profile Activation
Priorität: 6/10
Warum wichtig: JDK-Profile koennen hilfreich sein, aber Builds schwer vergleichbar machen.
Typischer Fehler: Ein Modul baut unter Java 21 anders als unter Java 17 ohne klare Fehlermeldung.
Enterprise-Einordnung: Geeignet fuer Migrationen, nicht fuer Dauerzustand.
Konfigurationsbeispiel
<profile>
  <id>java-21</id>
  <activation>
    <jdk>[21,)</jdk>
  </activation>
  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>
</profile>

mvn087: OS-Profile vermeiden oder isolieren

Englischer technischer Begriff: OS Profile
Priorität: 5/10
Warum wichtig: OS-Profile machen Builds plattformabhaengig.
Typischer Fehler: Windows erzeugt andere Artefakte als Linux-CI.
Enterprise-Einordnung: Nur fuer native Spezialfaelle akzeptabel.
Konfigurationsbeispiel
<profile>
  <id>linux-native-tools</id>
  <activation>
    <os><family>unix</family></os>
  </activation>
  <properties>
    <native.classifier>linux-x86_64</native.classifier>
  </properties>
</profile>

mvn088: Property-Aktivierung fuer CI nutzen

Englischer technischer Begriff: Property Profile Activation
Priorität: 7/10
Warum wichtig: Eine CI-Property ist explizit und in Pipeline-Logs sichtbar.
Typischer Fehler: Lokale Builds aktivieren zufaellig CI-Profile durch Umgebungsvariablen.
Enterprise-Einordnung: Gut fuer Pull-Request-Pipelines.
Konfigurationsbeispiel
<profile>
  <id>ci-quality</id>
  <activation>
    <property><name>env.CI</name></property>
  </activation>
  <properties>
    <skip.security.scan>false</skip.security.scan>
  </properties>
</profile>

mvn089: Default-Profil bewusst deaktivierbar machen

Englischer technischer Begriff: Active by Default Profile
Priorität: 6/10
Warum wichtig: activeByDefault ist bequem, muss aber durch andere Profile klar ersetzt werden.
Typischer Fehler: Ein Profil bleibt aktiv, obwohl ein spezialisiertes Profil erwartet wurde.
Enterprise-Einordnung: Nuetzlich fuer lokale Defaults.
Konfigurationsbeispiel
<profile>
  <id>local-defaults</id>
  <activation><activeByDefault>true</activeByDefault></activation>
  <properties>
    <database.url>jdbc:postgresql://localhost:5432/commerce</database.url>
  </properties>
</profile>

mvn090: Keine Secrets in POM-Profilen speichern

Englischer technischer Begriff: No Secrets in POM
Priorität: 10/10
Warum wichtig: POMs liegen im Git und duerfen keine Passwoerter enthalten.
Typischer Fehler: Repository-Credentials oder Tokens landen im Quellcode.
Enterprise-Einordnung: Kritisch fuer Security und Compliance.
Konfigurationsbeispiel
<profile>
  <id>internal-repository</id>
  <properties>
    <repo.release.url>https://repo.acme.local/maven/releases</repo.release.url>
  </properties>
</profile>
<!-- Credentials gehoeren in settings.xml oder Secret Store, nicht hier. -->

mvn091: CI-friendly Versions sauber konfigurieren

Englischer technischer Begriff: CI Friendly Versions
Priorität: 8/10
Warum wichtig: revision, sha1 und changelist erlauben Pipeline-gesteuerte Versionen.
Typischer Fehler: Man mischt manuelle Versionen und CI-Properties inkonsistent.
Enterprise-Einordnung: Nuetzlich fuer automatisierte Release-Prozesse.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>order-service</artifactId>
  <version>${revision}${changelist}</version>
  <properties>
    <revision>1.12.0</revision>
    <changelist>-SNAPSHOT</changelist>
  </properties>
</project>

mvn092: Profile fuer Release-Haertung nutzen

Englischer technischer Begriff: Release Profile
Priorität: 8/10
Warum wichtig: Ein Release-Profil aktiviert strengere Regeln als lokaler Entwicklungsbuild.
Typischer Fehler: Release laeuft mit denselben lockeren Regeln wie lokaler Build.
Enterprise-Einordnung: Geeignet fuer Deploy, Signatur, SBOM und Release-Deps.
Konfigurationsbeispiel
<profile>
  <id>release</id>
  <properties>
    <skip.unit.tests>false</skip.unit.tests>
    <skip.integration.tests>false</skip.integration.tests>
    <enforcer.require.release.deps>true</enforcer.require.release.deps>
  </properties>
</profile>

mvn093: Property-Namen fachlich gruppieren

Englischer technischer Begriff: Property Naming
Priorität: 6/10
Warum wichtig: Namensraeume wie acme.*, skip.* oder plugin.* machen POMs lesbarer.
Typischer Fehler: Properties heissen v1, version2 oder tempFlag.
Enterprise-Einordnung: Hilft bei grossen Parent-POMs.
Konfigurationsbeispiel
<properties>
  <acme.platform.release>2026.07</acme.platform.release>
  <plugin.compiler.version>${maven.compiler.plugin.version}</plugin.compiler.version>
  <skip.contract.tests>false</skip.contract.tests>
</properties>

mvn094: Umgebungswerte nicht hart filtern

Englischer technischer Begriff: Runtime Config Separation
Priorität: 8/10
Warum wichtig: Build-Filterung ist nicht dasselbe wie Laufzeitkonfiguration.
Typischer Fehler: Produktions-URL wird in das Jar gebrannt.
Enterprise-Einordnung: Wichtig fuer Container, Kubernetes und OpenShift.
Konfigurationsbeispiel
<properties>
  <build.profile.name>ci</build.profile.name>
</properties>
<!-- Laufzeitwerte wie DB Passwort und Service-URLs kommen aus Environment/Secret, nicht aus Maven. -->

mvn095: Profile in settings.xml fuer Benutzerkontext

Englischer technischer Begriff: Settings Profile
Priorität: 7/10
Warum wichtig: Benutzerspezifische Werte gehoeren in settings.xml.
Typischer Fehler: Jeder Entwickler aendert das Projekt-POM fuer lokale Pfade.
Enterprise-Einordnung: Trennt Projektstandard von Arbeitsplatzkonfiguration.
Konfigurationsbeispiel
<settings>
  <profiles>
    <profile>
      <id>acme-local</id>
      <properties>
        <docker.host>tcp://localhost:2375</docker.host>
      </properties>
    </profile>
  </profiles>
  <activeProfiles><activeProfile>acme-local</activeProfile></activeProfiles>
</settings>

mvn096: Profilkombinationen klein halten

Englischer technischer Begriff: Profile Matrix Control
Priorität: 6/10
Warum wichtig: Zu viele Profile erzeugen untestbare Build-Kombinationen.
Typischer Fehler: dev+ci+docker+native+release ergeben widerspruechliche Einstellungen.
Enterprise-Einordnung: Wichtig fuer nachvollziehbare Pipeline-Matrix.
Konfigurationsbeispiel
mvn -Pci verify
mvn -Prelease deploy
# Keine zufaelligen Kombis wie -Pdev,ci,release,native ohne dokumentierte Matrix.
08. Ressourcen, Filtering und Encoding 12 Einträge

mvn097: UTF-8 konsequent setzen

Englischer technischer Begriff: Source and Reporting Encoding
Priorität: 10/10
Warum wichtig: Encoding-Unterschiede erzeugen kaputte Umlaute und nicht reproduzierbare Dateien.
Typischer Fehler: Lokal Windows-1252, CI UTF-8.
Enterprise-Einordnung: Pflicht fuer deutsche Dokumentation und Enterprise-Konfigurationen.
Konfigurationsbeispiel
<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

mvn098: Filtering nur fuer passende Dateien aktivieren

Englischer technischer Begriff: Selective Resource Filtering
Priorität: 9/10
Warum wichtig: Filtering kann Binaries zerstoeren, wenn es global aktiviert wird.
Typischer Fehler: PNG, Keystore oder PDF wird durch Maven-Filtering kaputt.
Enterprise-Einordnung: Wichtig bei Zertifikaten und Assets.
Konfigurationsbeispiel
<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>false</filtering>
    </resource>
    <resource>
      <directory>src/main/filtered-resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build>

mvn099: Nicht filterbare Dateitypen schuetzen

Englischer technischer Begriff: Non Filtered File Extensions
Priorität: 8/10
Warum wichtig: Binary-Dateien muessen explizit vom Filtering ausgeschlossen sein.
Typischer Fehler: p12 oder jks wird nach Build unbrauchbar.
Enterprise-Einordnung: Kritisch fuer Security-Artefakte.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-resources-plugin</artifactId>
  <configuration>
    <encoding>UTF-8</encoding>
    <nonFilteredFileExtensions>
      <nonFilteredFileExtension>p12</nonFilteredFileExtension>
      <nonFilteredFileExtension>jks</nonFilteredFileExtension>
      <nonFilteredFileExtension>png</nonFilteredFileExtension>
    </nonFilteredFileExtensions>
  </configuration>
</plugin>

mvn100: Eigene Filterdateien fuer Buildmetadaten

Englischer technischer Begriff: Filter Files
Priorität: 7/10
Warum wichtig: Filterdateien kapseln Werte fuer Ressourcenfilterung.
Typischer Fehler: Properties werden verstreut in Profilen und Ressourcen gepflegt.
Enterprise-Einordnung: Nuetzlich fuer Build-Info ohne Secrets.
Konfigurationsbeispiel
<build>
  <filters>
    <filter>src/build/filters/build-info.properties</filter>
  </filters>
  <resources>
    <resource>
      <directory>src/main/build-info</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build>

mvn101: Delimiter bewusst konfigurieren

Englischer technischer Begriff: Resource Delimiters
Priorität: 6/10
Warum wichtig: Eigene Delimiter verhindern Konflikte mit Spring- oder Shell-Syntax.
Typischer Fehler: ${...} wird versehentlich in YAML oder Shell-Dateien ersetzt.
Enterprise-Einordnung: Hilfreich bei gemischten Konfigurationsformaten.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-resources-plugin</artifactId>
  <configuration>
    <useDefaultDelimiters>false</useDefaultDelimiters>
    <delimiters>
      <delimiter>@</delimiter>
    </delimiters>
  </configuration>
</plugin>

mvn102: Buildmetadaten als Ressource erzeugen

Englischer technischer Begriff: Build Info Resource
Priorität: 7/10
Warum wichtig: Build-Info macht Artefaktversion und Revision zur Laufzeit sichtbar.
Typischer Fehler: Im Betrieb ist unklar, welcher Git-Stand laeuft.
Enterprise-Einordnung: Wichtig fuer Diagnose und Support.
Konfigurationsbeispiel
<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
    </resource>
    <resource>
      <directory>src/main/build-info</directory>
      <filtering>true</filtering>
      <includes><include>build-info.properties</include></includes>
    </resource>
  </resources>
</build>

mvn103: Test-Ressourcen getrennt filtern

Englischer technischer Begriff: Test Resource Filtering
Priorität: 7/10
Warum wichtig: Testdaten koennen andere Werte brauchen als Produktionsressourcen.
Typischer Fehler: Test-URLs landen in main resources.
Enterprise-Einordnung: Verbessert Testisolation.
Konfigurationsbeispiel
<build>
  <testResources>
    <testResource>
      <directory>src/test/resources</directory>
      <filtering>true</filtering>
    </testResource>
  </testResources>
</build>

mvn104: Resource-Includes explizit setzen

Englischer technischer Begriff: Resource Includes
Priorität: 6/10
Warum wichtig: Includes reduzieren versehentlich mitgepackte Dateien.
Typischer Fehler: README, lokale Dumps oder Beispiel-Secrets landen im Jar.
Enterprise-Einordnung: Wichtig fuer schlanke und sichere Artefakte.
Konfigurationsbeispiel
<resource>
  <directory>src/main/resources</directory>
  <includes>
    <include>application.yaml</include>
    <include>db/migration/**</include>
    <include>META-INF/services/**</include>
  </includes>
</resource>

mvn105: Resource-Excludes fuer lokale Dateien

Englischer technischer Begriff: Resource Excludes
Priorität: 7/10
Warum wichtig: Excludes verhindern lokale oder sensible Dateien im Artefakt.
Typischer Fehler: application-local.yaml wird produktiv ausgeliefert.
Enterprise-Einordnung: Praktisch fuer Entwicklerprofile.
Konfigurationsbeispiel
<resource>
  <directory>src/main/resources</directory>
  <excludes>
    <exclude>application-local.yaml</exclude>
    <exclude>**/*.bak</exclude>
    <exclude>secrets/**</exclude>
  </excludes>
</resource>

mvn106: Properties-Dateien nicht fuer Secrets nutzen

Englischer technischer Begriff: No Secrets in Resources
Priorität: 10/10
Warum wichtig: Ressourcen landen im Artefakt und koennen extrahiert werden.
Typischer Fehler: Passwoerter werden in application.properties eingebaut.
Enterprise-Einordnung: Kritisch fuer Container und Cloud-Betrieb.
Konfigurationsbeispiel
<resource>
  <directory>src/main/resources</directory>
  <excludes>
    <exclude>**/*secret*</exclude>
    <exclude>**/*password*</exclude>
  </excludes>
</resource>
<!-- Secrets zur Laufzeit aus Vault/Kubernetes Secret/Environment laden. -->

mvn107: Line-Endings in Ressourcen beachten

Englischer technischer Begriff: Line Ending Stability
Priorität: 5/10
Warum wichtig: Unterschiedliche Line-Endings koennen Checksums und Skripte beeinflussen.
Typischer Fehler: Shell-Skripte aus Windows-Checkout laufen in Linux-Containern nicht.
Enterprise-Einordnung: Relevant fuer Container-Entrypoints.
Konfigurationsbeispiel
<resource>
  <directory>src/main/scripts</directory>
  <targetPath>bin</targetPath>
  <filtering>true</filtering>
  <includes><include>*.sh</include></includes>
</resource>

mvn108: ServiceLoader-Dateien bewusst packen

Englischer technischer Begriff: META-INF Services
Priorität: 6/10
Warum wichtig: ServiceLoader-Dateien muessen im richtigen Pfad landen.
Typischer Fehler: SPI-Implementierungen werden zur Laufzeit nicht gefunden.
Enterprise-Einordnung: Wichtig fuer JDBC, Logging, Plugins und Framework-SPIs.
Konfigurationsbeispiel
<resource>
  <directory>src/main/resources</directory>
  <includes>
    <include>META-INF/services/**</include>
  </includes>
</resource>
09. Repositories, Mirrors und settings.xml 17 Einträge

mvn109: Credentials nur in settings.xml speichern

Englischer technischer Begriff: Settings Credentials
Priorität: 10/10
Warum wichtig: Credentials gehoeren nicht ins Projekt-POM.
Typischer Fehler: Repository-Passwoerter landen im Git.
Enterprise-Einordnung: Security-Basics fuer jedes Enterprise-Maven.
Konfigurationsbeispiel
<settings>
  <servers>
    <server>
      <id>acme-releases</id>
      <username>${env.REPO_USER}</username>
      <password>${env.REPO_TOKEN}</password>
    </server>
  </servers>
</settings>

mvn110: Server-ID muss Repository-ID entsprechen

Englischer technischer Begriff: Repository Server Id Match
Priorität: 9/10
Warum wichtig: Maven ordnet Credentials ueber die id zu.
Typischer Fehler: settings.xml hat `nexus`, POM hat `acme-releases`; Deployment ist 401.
Enterprise-Einordnung: Wichtig fuer Deployments und interne Repository Manager.
Konfigurationsbeispiel
<distributionManagement>
  <repository>
    <id>acme-releases</id>
    <url>https://repo.acme.local/maven/releases</url>
  </repository>
</distributionManagement>
<!-- settings.xml: <server><id>acme-releases</id>...</server> -->

mvn111: Mirror fuer alle externen Repositories setzen

Englischer technischer Begriff: Repository Mirror
Priorität: 10/10
Warum wichtig: Ein Mirror erzwingt zentrale Kontrolle ueber externe Artefakte.
Typischer Fehler: Builds laden direkt aus dem Internet und umgehen Security-Scan.
Enterprise-Einordnung: Pflicht in vielen Unternehmen.
Konfigurationsbeispiel
<settings>
  <mirrors>
    <mirror>
      <id>acme-maven-proxy</id>
      <mirrorOf>*</mirrorOf>
      <url>https://repo.acme.local/maven/proxy</url>
    </mirror>
  </mirrors>
</settings>

mvn112: Snapshots und Releases trennen

Englischer technischer Begriff: Snapshot Release Separation
Priorität: 9/10
Warum wichtig: Snapshots sind veraenderlich, Releases sollten unveraenderlich sein.
Typischer Fehler: Release-Build loest Snapshot-Artefakte auf.
Enterprise-Einordnung: Wichtig fuer Reproduzierbarkeit.
Konfigurationsbeispiel
<repository>
  <id>acme-releases</id>
  <url>https://repo.acme.local/maven/releases</url>
  <releases><enabled>true</enabled></releases>
  <snapshots><enabled>false</enabled></snapshots>
</repository>

mvn113: Snapshot-Repository separat konfigurieren

Englischer technischer Begriff: Snapshot Repository
Priorität: 8/10
Warum wichtig: Snapshot-Repositories haben andere Retention und Update-Regeln.
Typischer Fehler: Snapshots werden in Release-Repositories deployed.
Enterprise-Einordnung: Wichtig fuer CI Branch Builds.
Konfigurationsbeispiel
<snapshotRepository>
  <id>acme-snapshots</id>
  <url>https://repo.acme.local/maven/snapshots</url>
</snapshotRepository>

mvn114: Plugin-Repositories nicht vergessen

Englischer technischer Begriff: Plugin Repositories
Priorität: 7/10
Warum wichtig: Plugins werden aus pluginRepositories aufgeloest, nicht aus repositories allein.
Typischer Fehler: Dependencies funktionieren, Plugin-Aufloesung scheitert.
Enterprise-Einordnung: Relevant bei internen oder gespiegelten Plugins.
Konfigurationsbeispiel
<pluginRepositories>
  <pluginRepository>
    <id>acme-plugin-releases</id>
    <url>https://repo.acme.local/maven/plugin-releases</url>
    <snapshots><enabled>false</enabled></snapshots>
  </pluginRepository>
</pluginRepositories>

mvn115: Repository-Definitionen bevorzugt zentralisieren

Englischer technischer Begriff: Central Repository Configuration
Priorität: 8/10
Warum wichtig: settings.xml oder Parent verhindert Modulduplikate.
Typischer Fehler: Jedes Modul pflegt andere URLs.
Enterprise-Einordnung: Vereinheitlicht Netzwerk- und Security-Verhalten.
Konfigurationsbeispiel
<settings>
  <profiles>
    <profile>
      <id>acme-repositories</id>
      <repositories>
        <repository>
          <id>acme-releases</id>
          <url>https://repo.acme.local/maven/releases</url>
        </repository>
      </repositories>
    </profile>
  </profiles>
  <activeProfiles><activeProfile>acme-repositories</activeProfile></activeProfiles>
</settings>

mvn116: UpdatePolicy fuer Snapshots bewusst setzen

Englischer technischer Begriff: Snapshot Update Policy
Priorität: 6/10
Warum wichtig: UpdatePolicy beeinflusst, wie oft Maven Snapshot-Metadaten prueft.
Typischer Fehler: Entwickler wundern sich ueber alte Snapshot-Versionen.
Enterprise-Einordnung: Relevant fuer schnelle Integrationszyklen.
Konfigurationsbeispiel
<repository>
  <id>acme-snapshots</id>
  <url>https://repo.acme.local/maven/snapshots</url>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>always</updatePolicy>
  </snapshots>
</repository>

mvn117: ChecksumPolicy streng waehlen

Englischer technischer Begriff: Checksum Policy
Priorität: 8/10
Warum wichtig: Checksums schuetzen vor korrupten oder manipulierten Artefakten.
Typischer Fehler: Warnungen werden ignoriert und Build laeuft mit kaputtem Artefakt weiter.
Enterprise-Einordnung: Supply-Chain-Haertung.
Konfigurationsbeispiel
<repository>
  <id>acme-releases</id>
  <url>https://repo.acme.local/maven/releases</url>
  <releases>
    <enabled>true</enabled>
    <checksumPolicy>fail</checksumPolicy>
  </releases>
</repository>

mvn118: Offline-Modus fuer reproduzierbare Checks nutzen

Englischer technischer Begriff: Offline Mode
Priorität: 6/10
Warum wichtig: Offline-Modus prueft, ob alle Artefakte lokal vorbereitet sind.
Typischer Fehler: CI haengt an Netzwerkproblemen oder zieht unkontrolliert Updates.
Enterprise-Einordnung: Nuetzlich fuer gesicherte Build-Umgebungen.
Konfigurationsbeispiel
mvn dependency:go-offline
mvn -o -B verify

mvn119: Lokales Repository in CI isolieren

Englischer technischer Begriff: Isolated Local Repository
Priorität: 8/10
Warum wichtig: Ein isoliertes .m2 verhindert Cross-Job-Verschmutzung.
Typischer Fehler: Ein alter Snapshot aus anderem Job wird verwendet.
Enterprise-Einordnung: Wichtig fuer reproduzierbare Pipelines.
Konfigurationsbeispiel
mvn -Dmaven.repo.local=.m2/repository -B verify

mvn120: settings-security.xml fuer verschluesselte Passwoerter

Englischer technischer Begriff: Encrypted Maven Passwords
Priorität: 7/10
Warum wichtig: Maven kann Passwoerter verschluesselt speichern, besser sind oft CI-Secrets.
Typischer Fehler: Plaintext-Passwoerter liegen im Home-Verzeichnis.
Enterprise-Einordnung: Gut fuer klassische Build-Server.
Konfigurationsbeispiel
<settingsSecurity>
  <master>{encrypted-master-password}</master>
</settingsSecurity>

mvn121: Proxy-Konfiguration in settings.xml halten

Englischer technischer Begriff: Maven Proxy
Priorität: 6/10
Warum wichtig: Unternehmensproxies gehoeren in settings.xml, nicht in POMs.
Typischer Fehler: Projekte enthalten lokale Proxy-Hosts.
Enterprise-Einordnung: Trennt Infrastruktur von Sourcecode.
Konfigurationsbeispiel
<settings>
  <proxies>
    <proxy>
      <id>acme-proxy</id>
      <active>true</active>
      <protocol>https</protocol>
      <host>proxy.acme.local</host>
      <port>8080</port>
      <nonProxyHosts>*.acme.local|localhost</nonProxyHosts>
    </proxy>
  </proxies>
</settings>

mvn122: MirrorOf gezielt fuer interne Repos ausschliessen

Englischer technischer Begriff: MirrorOf Pattern
Priorität: 6/10
Warum wichtig: mirrorOf kann interne Repositories ausnehmen, wenn noetig.
Typischer Fehler: Ein Mirror greift auch fuer Repos, die direkt erreichbar sein sollen.
Enterprise-Einordnung: Nützlich bei Migrationsphasen.
Konfigurationsbeispiel
<mirror>
  <id>acme-external-proxy</id>
  <mirrorOf>external:*</mirrorOf>
  <url>https://repo.acme.local/maven/external-proxy</url>
</mirror>

mvn123: Deployment-Repository nicht per Kommando verstecken

Englischer technischer Begriff: Visible Distribution Management
Priorität: 7/10
Warum wichtig: Distribution gehoert nachvollziehbar ins POM/Parent.
Typischer Fehler: CI deployt mit langer altDeploymentRepository-Option, die niemand sieht.
Enterprise-Einordnung: Besser fuer Audits und Releases.
Konfigurationsbeispiel
<distributionManagement>
  <repository>
    <id>acme-releases</id>
    <url>https://repo.acme.local/maven/releases</url>
  </repository>
</distributionManagement>

mvn124: Repository Layout modern halten

Englischer technischer Begriff: Default Repository Layout
Priorität: 5/10
Warum wichtig: Das default layout ist Standard fuer moderne Maven-Repositories.
Typischer Fehler: Alte legacy-Layouts werden ohne Not weiterverwendet.
Enterprise-Einordnung: Relevant bei sehr alten Nexus/Artifactory-Migrationen.
Konfigurationsbeispiel
<repository>
  <id>acme-releases</id>
  <url>https://repo.acme.local/maven/releases</url>
  <layout>default</layout>
</repository>

mvn125: Niemals file:// Repositories fuer Team-Builds

Englischer technischer Begriff: Avoid File Repositories
Priorität: 8/10
Warum wichtig: file-Repositories sind nicht portabel und umgehen Governance.
Typischer Fehler: Artefakte werden ueber Netzlaufwerk statt Repository Manager verteilt.
Enterprise-Einordnung: Enterprise-Builds brauchen zentrale Repositories.
Konfigurationsbeispiel
<!-- Besser als file://share/libs: internes Repository verwenden. -->
<repository>
  <id>acme-vendor-releases</id>
  <url>https://repo.acme.local/maven/vendor-releases</url>
</repository>
10. Toolchains, JDK und Compiler-Konfiguration 10 Einträge

mvn126: Compiler release statt source/target bevorzugen

Englischer technischer Begriff: Compiler Release
Priorität: 10/10
Warum wichtig: release setzt API-Level und Bytecode konsistent.
Typischer Fehler: source/target 17 kompiliert gegen Java-21-APIs.
Enterprise-Einordnung: Wichtig fuer Laufzeitkompatibilitaet.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <release>21</release>
    <parameters>true</parameters>
  </configuration>
</plugin>

mvn127: Parameter-Namen fuer Reflection erhalten

Englischer technischer Begriff: Compiler Parameters
Priorität: 8/10
Warum wichtig: -parameters ermoeglicht Frameworks bessere Reflection auf Methodenparameter.
Typischer Fehler: Spring/Jakarta Binding verliert Parameternamen.
Enterprise-Einordnung: Relevant fuer Controller, DI und Validierung.
Konfigurationsbeispiel
<configuration>
  <release>21</release>
  <parameters>true</parameters>
</configuration>

mvn128: Toolchains fuer feste JDK-Auswahl verwenden

Englischer technischer Begriff: Maven Toolchains
Priorität: 9/10
Warum wichtig: Toolchains trennen Maven-JDK vom Build-JDK.
Typischer Fehler: Entwickler bauen zufaellig mit installiertem Default-JDK.
Enterprise-Einordnung: Wichtig fuer parallele Java-Versionen und CI.
Konfigurationsbeispiel
<toolchains>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>21</version>
      <vendor>temurin</vendor>
    </provides>
    <configuration>
      <jdkHome>/opt/jdks/temurin-21</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

mvn129: Toolchains im POM anfordern

Englischer technischer Begriff: Toolchain Requirement
Priorität: 8/10
Warum wichtig: Das Projekt fordert eine Toolchain; settings/toolchains.xml liefert den konkreten Pfad.
Typischer Fehler: POM sagt Java 21, aber CI nutzt anderes JDK.
Enterprise-Einordnung: Sichert Build-Baseline.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-toolchains-plugin</artifactId>
  <executions>
    <execution>
      <goals><goal>toolchain</goal></goals>
    </execution>
  </executions>
  <configuration>
    <toolchains>
      <jdk><version>21</version><vendor>temurin</vendor></jdk>
    </toolchains>
  </configuration>
</plugin>

mvn130: Preview-Features nicht unbeabsichtigt aktivieren

Englischer technischer Begriff: Preview Features Control
Priorität: 8/10
Warum wichtig: Preview-Features binden Artefakte an spezielle Runtime-Flags.
Typischer Fehler: Code kompiliert nur mit --enable-preview und bricht produktiv.
Enterprise-Einordnung: Nur bewusst fuer Lab oder Forschung.
Konfigurationsbeispiel
<configuration>
  <release>21</release>
  <compilerArgs>
    <arg>-Xlint:all</arg>
  </compilerArgs>
</configuration>
<!-- Kein --enable-preview fuer normale Enterprise-Releases. -->

mvn131: Warnungen im Compiler sichtbar machen

Englischer technischer Begriff: Compiler Warnings
Priorität: 7/10
Warum wichtig: Warnungen zeigen veraltete APIs und unsichere Muster frueh.
Typischer Fehler: Build ignoriert Deprecations und unchecked Casts jahrelang.
Enterprise-Einordnung: Gut fuer Modernisierung.
Konfigurationsbeispiel
<configuration>
  <showWarnings>true</showWarnings>
  <compilerArgs>
    <arg>-Xlint:deprecation</arg>
    <arg>-Xlint:unchecked</arg>
  </compilerArgs>
</configuration>

mvn132: Annotation Processor explizit konfigurieren

Englischer technischer Begriff: Explicit Annotation Processors
Priorität: 8/10
Warum wichtig: Explizite Processor-Pfade machen Build reproduzierbar.
Typischer Fehler: Processor werden zufaellig aus compile classpath genommen.
Enterprise-Einordnung: Wichtig fuer MapStruct, Lombok, JPA Metamodel.
Konfigurationsbeispiel
<configuration>
  <annotationProcessorPaths>
    <path>
      <groupId>org.mapstruct</groupId>
      <artifactId>mapstruct-processor</artifactId>
      <version>${mapstruct.version}</version>
    </path>
  </annotationProcessorPaths>
</configuration>

mvn133: Modulpfad bei Legacy bewusst deaktivieren

Englischer technischer Begriff: Module Path Control
Priorität: 6/10
Warum wichtig: Bei nicht modularisierten Legacy-Projekten kann module path Probleme verursachen.
Typischer Fehler: Tests schlagen wegen JPMS-Zugriffen fehl.
Enterprise-Einordnung: Pragmatisch fuer Migrationen.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <useModulePath>false</useModulePath>
  </configuration>
</plugin>

mvn134: Multi-Release-Jars nur bewusst bauen

Englischer technischer Begriff: Multi Release Jar
Priorität: 5/10
Warum wichtig: Multi-Release-Jars sind komplex und brauchen klare Tests.
Typischer Fehler: Runtime laedt andere Klassen als lokal erwartet.
Enterprise-Einordnung: Nur fuer Libraries mit starken Kompatibilitaetsanforderungen.
Konfigurationsbeispiel
<archive>
  <manifestEntries>
    <Multi-Release>true</Multi-Release>
  </manifestEntries>
</archive>

mvn135: Java-Version mit Enforcer absichern

Englischer technischer Begriff: Enforced Java Version
Priorität: 9/10
Warum wichtig: Compiler-Konfiguration allein verhindert nicht falsche Runtime im Build.
Typischer Fehler: CI startet Maven mit alter Java-Version.
Enterprise-Einordnung: Kombination aus Compiler und Enforcer ist robust.
Konfigurationsbeispiel
<rules>
  <requireJavaVersion>
    <version>[21,)</version>
    <message>Dieses Projekt benoetigt mindestens Java 21.</message>
  </requireJavaVersion>
</rules>
11. Tests, Quality Gates und Analyse 14 Einträge

mvn136: Unit-Tests mit Surefire trennen

Englischer technischer Begriff: Unit Test Convention
Priorität: 9/10
Warum wichtig: Surefire ist fuer schnelle Unit-Tests im test-Lifecycle.
Typischer Fehler: Integrationstests laufen als Unit-Tests und machen Feedback langsam.
Enterprise-Einordnung: Grundlage fuer CI-Stufen.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <includes>
      <include>**/*Test.java</include>
      <include>**/*Tests.java</include>
    </includes>
  </configuration>
</plugin>

mvn137: Integrationstests mit Failsafe benennen

Englischer technischer Begriff: Integration Test Convention
Priorität: 9/10
Warum wichtig: Failsafe wertet Integrationstests in verify korrekt aus.
Typischer Fehler: ITs heissen *Test und laufen zu frueh.
Enterprise-Einordnung: Wichtig fuer Datenbanken, Messaging und Container.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-failsafe-plugin</artifactId>
  <configuration>
    <includes>
      <include>**/*IT.java</include>
      <include>**/*IntegrationTest.java</include>
    </includes>
  </configuration>
</plugin>

mvn138: Tests nicht global skippen

Englischer technischer Begriff: Avoid Global Test Skip
Priorität: 10/10
Warum wichtig: -DskipTests kompiliert Tests noch; -Dmaven.test.skip=true ueberspringt sogar Testkompilierung.
Typischer Fehler: CI verwendet dauerhaft maven.test.skip und merkt Testkompilierungsfehler nicht.
Enterprise-Einordnung: Kritisch fuer Release-Qualitaet.
Konfigurationsbeispiel
mvn -DskipTests package
# Nur fuer Sonderfaelle: mvn -Dmaven.test.skip=true package

mvn139: Test-Zeitzone stabil setzen

Englischer technischer Begriff: Stable Test Timezone
Priorität: 7/10
Warum wichtig: Zeitzonenunterschiede verursachen flakige Datumstests.
Typischer Fehler: Lokal Europa/Wien, CI UTC.
Enterprise-Einordnung: Wichtig fuer internationale Enterprise-Systeme.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <systemPropertyVariables>
      <user.timezone>UTC</user.timezone>
    </systemPropertyVariables>
  </configuration>
</plugin>

mvn140: Test-Forks bewusst konfigurieren

Englischer technischer Begriff: Surefire Forks
Priorität: 7/10
Warum wichtig: Forks isolieren JVM-Zustand, kosten aber Zeit.
Typischer Fehler: Statische Zustände leaken zwischen Tests.
Enterprise-Einordnung: Hilft bei stabiler Testausfuehrung.
Konfigurationsbeispiel
<configuration>
  <forkCount>1</forkCount>
  <reuseForks>true</reuseForks>
  <forkedProcessTimeoutInSeconds>120</forkedProcessTimeoutInSeconds>
</configuration>

mvn141: Coverage als Gate definieren

Englischer technischer Begriff: Coverage Gate
Priorität: 8/10
Warum wichtig: Coverage-Gates verhindern unbeabsichtigten Rueckgang.
Typischer Fehler: Coverage wird nur als Bericht erzeugt und nie bewertet.
Enterprise-Einordnung: Teil der Quality Governance.
Konfigurationsbeispiel
<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <executions>
    <execution><goals><goal>prepare-agent</goal></goals></execution>
    <execution>
      <id>check-coverage</id>
      <phase>verify</phase>
      <goals><goal>check</goal></goals>
      <configuration>
        <rules>
          <rule>
            <element>BUNDLE</element>
            <limits><limit><counter>LINE</counter><value>COVEREDRATIO</value><minimum>0.75</minimum></limit></limits>
          </rule>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

mvn142: Statische Analyse im verify-Lifecycle

Englischer technischer Begriff: Static Analysis in Verify
Priorität: 8/10
Warum wichtig: Analyse in verify macht sie zum echten Gate.
Typischer Fehler: Checks laufen nur lokal manuell.
Enterprise-Einordnung: Wichtig fuer Teamskalierung.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <executions>
    <execution>
      <id>checkstyle-gate</id>
      <phase>verify</phase>
      <goals><goal>check</goal></goals>
    </execution>
  </executions>
</plugin>

mvn143: Flaky Tests sichtbar markieren

Englischer technischer Begriff: Flaky Test Handling
Priorität: 7/10
Warum wichtig: Flaky Tests duerfen nicht still ignoriert werden.
Typischer Fehler: Reruns verstecken systematische Race Conditions.
Enterprise-Einordnung: Wichtig fuer Concurrency und Integrationstests.
Konfigurationsbeispiel
<configuration>
  <rerunFailingTestsCount>1</rerunFailingTestsCount>
  <failIfNoTests>true</failIfNoTests>
</configuration>

mvn144: Keine Tests gefunden als Fehler behandeln

Englischer technischer Begriff: Fail If No Tests
Priorität: 7/10
Warum wichtig: Leere Testlaeufe koennen Fehlkonfiguration anzeigen.
Typischer Fehler: Ein Modul laeuft ohne Tests, weil Includes falsch sind.
Enterprise-Einordnung: Hilft bei Refactoring und Modulmigration.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <failIfNoTests>true</failIfNoTests>
  </configuration>
</plugin>

mvn145: System Properties fuer Tests begrenzen

Englischer technischer Begriff: Test System Properties
Priorität: 6/10
Warum wichtig: Testproperties sollen explizit und klein sein.
Typischer Fehler: Tests haengen von zufaelligen Umgebungsvariablen ab.
Enterprise-Einordnung: Erhoeht Reproduzierbarkeit.
Konfigurationsbeispiel
<systemPropertyVariables>
  <acme.test.profile>unit</acme.test.profile>
  <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
</systemPropertyVariables>

mvn146: Integrationstest-Services ueber Profile starten

Englischer technischer Begriff: IT Profile
Priorität: 7/10
Warum wichtig: Teure ITs koennen bewusst ueber Profil laufen.
Typischer Fehler: Lokale Standardbuilds starten Docker oder externe Services ungewollt.
Enterprise-Einordnung: Gute Balance aus schnellem Feedback und Tiefe.
Konfigurationsbeispiel
<profile>
  <id>it</id>
  <properties>
    <skip.integration.tests>false</skip.integration.tests>
  </properties>
</profile>

mvn147: Mutation Testing nicht im Standardbuild erzwingen

Englischer technischer Begriff: Mutation Testing Placement
Priorität: 5/10
Warum wichtig: Mutation Tests sind wertvoll, aber langsam.
Typischer Fehler: Jeder PR-Build wird extrem langsam.
Enterprise-Einordnung: Eher nightly oder gezielt fuer kritische Module.
Konfigurationsbeispiel
mvn -Pmutation -pl services/payment-service test

mvn148: Quality Gates im Parent dokumentieren

Englischer technischer Begriff: Quality Gate Documentation
Priorität: 6/10
Warum wichtig: Teams muessen wissen, warum ein Gate existiert.
Typischer Fehler: Build bricht mit unbekannter Regel und wird deaktiviert.
Enterprise-Einordnung: Akzeptanz fuer Governance.
Konfigurationsbeispiel
<properties>
  <quality.gate.description>Unit tests, dependency convergence, style checks and coverage run in verify.</quality.gate.description>
</properties>

mvn149: Test-Jars nicht als Produktivvertrag nutzen

Englischer technischer Begriff: Test Jar Boundary
Priorität: 6/10
Warum wichtig: Test-Jars sind fuer Tests, nicht fuer Runtime-Integration.
Typischer Fehler: Produktivcode nutzt Klassen aus test-jar.
Enterprise-Einordnung: Saubere Contracts gehoeren in API-Module.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.contracts</groupId>
  <artifactId>order-contract-tests</artifactId>
  <version>1.12.0</version>
  <classifier>tests</classifier>
  <scope>test</scope>
</dependency>
12. Packaging, Artefakte und Deployment 14 Einträge

mvn150: FinalName nicht fuer Koordinaten missbrauchen

Englischer technischer Begriff: Final Name
Priorität: 6/10
Warum wichtig: finalName aendert Dateinamen, nicht Maven-Koordinaten.
Typischer Fehler: Man glaubt, artifactId/version wuerden dadurch anders deployt.
Enterprise-Einordnung: Wichtig fuer Artefaktablage und Container-Builds.
Konfigurationsbeispiel
<build>
  <finalName>order-service</finalName>
</build>

mvn151: Manifest mit Build-Informationen anreichern

Englischer technischer Begriff: Jar Manifest Entries
Priorität: 7/10
Warum wichtig: Manifestdaten helfen bei Diagnose und Support.
Typischer Fehler: Jar enthaelt keine Version oder Build-Revision.
Enterprise-Einordnung: Nuetzlich fuer klassische Deployments.
Konfigurationsbeispiel
<archive>
  <manifestEntries>
    <Implementation-Title>${project.artifactId}</Implementation-Title>
    <Implementation-Version>${project.version}</Implementation-Version>
    <Build-Jdk>${java.version}</Build-Jdk>
  </manifestEntries>
</archive>

mvn152: Sources und Javadocs fuer Libraries bereitstellen

Englischer technischer Begriff: Sources and Javadocs Artifacts
Priorität: 7/10
Warum wichtig: Consumer koennen APIs besser verstehen und debuggen.
Typischer Fehler: Interne Libraries sind Black Boxes.
Enterprise-Einordnung: Wichtig fuer Plattform- und API-Teams.
Konfigurationsbeispiel
<build>
  <plugins>
    <plugin>
      <artifactId>maven-source-plugin</artifactId>
      <executions><execution><id>attach-sources</id><goals><goal>jar-no-fork</goal></goals></execution></executions>
    </plugin>
    <plugin>
      <artifactId>maven-javadoc-plugin</artifactId>
      <executions><execution><id>attach-javadocs</id><goals><goal>jar</goal></goals></execution></executions>
    </plugin>
  </plugins>
</build>

mvn153: Test-Jar nur gezielt attachen

Englischer technischer Begriff: Attach Test Jar
Priorität: 5/10
Warum wichtig: Test-Jars koennen Fixtures teilen, sollten aber kontrolliert sein.
Typischer Fehler: Alle Tests werden ungeplant als Artefakt verteilt.
Enterprise-Einordnung: Nuetzlich fuer Contract-Test-Module.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-jar-plugin</artifactId>
  <executions>
    <execution>
      <id>attach-test-jar</id>
      <goals><goal>test-jar</goal></goals>
    </execution>
  </executions>
</plugin>

mvn154: War ohne web.xml bewusst erlauben

Englischer technischer Begriff: WAR without web.xml
Priorität: 6/10
Warum wichtig: Moderne Servlet/Jakarta-Anwendungen brauchen oft kein web.xml.
Typischer Fehler: Build bricht wegen fehlender web.xml.
Enterprise-Einordnung: Relevant fuer Spring Boot WAR oder moderne Jakarta Apps.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <failOnMissingWebXml>false</failOnMissingWebXml>
  </configuration>
</plugin>

mvn155: EAR-Module explizit beschreiben

Englischer technischer Begriff: EAR Modules
Priorität: 7/10
Warum wichtig: EAR-Packaging braucht klare Moduldefinitionen.
Typischer Fehler: WAR-Kontext oder EJB-Modul wird falsch erkannt.
Enterprise-Einordnung: Relevant fuer klassische Java EE/Jakarta EE Migrationen.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-ear-plugin</artifactId>
  <configuration>
    <version>8</version>
    <defaultLibBundleDir>lib</defaultLibBundleDir>
    <modules>
      <webModule>
        <groupId>com.acme.commerce</groupId>
        <artifactId>order-web</artifactId>
        <contextRoot>/orders</contextRoot>
      </webModule>
    </modules>
  </configuration>
</plugin>

mvn156: Assembly fuer Distributionen nutzen

Englischer technischer Begriff: Assembly Distribution
Priorität: 6/10
Warum wichtig: Assemblies packen Laufzeitdateien, Skripte und Docs reproduzierbar.
Typischer Fehler: Zip-Dateien werden manuell gebaut.
Enterprise-Einordnung: Nuetzlich fuer Batchjobs oder Legacy-Deployments.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <descriptors><descriptor>src/assembly/runtime.xml</descriptor></descriptors>
    <appendAssemblyId>false</appendAssemblyId>
  </configuration>
</plugin>

mvn157: Shade nur fuer echte Fat-Jar-Faelle

Englischer technischer Begriff: Shaded Jar Caution
Priorität: 6/10
Warum wichtig: Shading kann Konflikte loesen, aber auch Dependencies verstecken.
Typischer Fehler: Jede Anwendung wird automatisch als Fat Jar gebaut.
Enterprise-Einordnung: Bewusst fuer CLI/Standalone, vorsichtig fuer Libraries.
Konfigurationsbeispiel
<configuration>
  <createDependencyReducedPom>true</createDependencyReducedPom>
  <transformers>
    <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
  </transformers>
</configuration>

mvn158: Classifier fuer Zusatzartefakte verwenden

Englischer technischer Begriff: Attached Artifact Classifier
Priorität: 6/10
Warum wichtig: Classifier trennt Zusatzartefakte von Hauptartefakt.
Typischer Fehler: Schemas oder Migrationsskripte werden unter falschen Koordinaten deployed.
Enterprise-Einordnung: Gut fuer Contracts, DB-Skripte und OpenAPI-Dateien.
Konfigurationsbeispiel
<artifactItems>
  <artifactItem>
    <groupId>com.acme.contracts</groupId>
    <artifactId>order-openapi</artifactId>
    <version>${project.version}</version>
    <classifier>openapi</classifier>
    <type>yaml</type>
  </artifactItem>
</artifactItems>

mvn159: Deploy nur aus Release-Pipeline

Englischer technischer Begriff: Controlled Deploy
Priorität: 9/10
Warum wichtig: Deploy sollte kontrolliert und nachvollziehbar erfolgen.
Typischer Fehler: Jeder Entwickler deployed lokale Zwischenstaende.
Enterprise-Einordnung: Wichtig fuer Repository-Qualitaet.
Konfigurationsbeispiel
mvn -B -Prelease clean deploy
# Nur aus geschuetztem CI-Branch mit signierten Credentials.

mvn160: Snapshot-Versionen klar kennzeichnen

Englischer technischer Begriff: Snapshot Versioning
Priorität: 8/10
Warum wichtig: SNAPSHOT zeigt veraenderliche Zwischenstaende.
Typischer Fehler: Nicht freigegebene Artefakte bekommen Release-Versionen.
Enterprise-Einordnung: Hilft bei Branch- und Integrationsbuilds.
Konfigurationsbeispiel
<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>
  <groupId>com.acme.commerce</groupId>
  <artifactId>payment-service</artifactId>
  <version>2.5.0-SNAPSHOT</version>
  <packaging>jar</packaging>
</project>

mvn161: Release-Versionen unveraenderlich behandeln

Englischer technischer Begriff: Immutable Releases
Priorität: 10/10
Warum wichtig: Releases duerfen nicht ueberschrieben werden.
Typischer Fehler: Version 1.2.0 wird mehrfach mit anderem Inhalt deployed.
Enterprise-Einordnung: Grundregel fuer Reproduzierbarkeit.
Konfigurationsbeispiel
<repository>
  <id>acme-releases</id>
  <url>https://repo.acme.local/maven/releases</url>
  <releases><enabled>true</enabled><updatePolicy>never</updatePolicy></releases>
</repository>

mvn162: Artifact Attachment fuer generierte Dateien

Englischer technischer Begriff: Attach Generated Artifacts
Priorität: 6/10
Warum wichtig: Generierte Contracts koennen als eigenes Artefakt verteilt werden.
Typischer Fehler: OpenAPI-Datei wird per Mail oder Wiki verteilt.
Enterprise-Einordnung: Besser fuer Contract Governance.
Konfigurationsbeispiel
<execution>
  <id>attach-openapi-contract</id>
  <phase>package</phase>
  <goals><goal>attach-artifact</goal></goals>
  <configuration>
    <artifacts>
      <artifact>
        <file>${project.build.directory}/openapi/order-service.yaml</file>
        <type>yaml</type>
        <classifier>openapi</classifier>
      </artifact>
    </artifacts>
  </configuration>
</execution>

mvn163: Container-Build nicht mit Maven-Artefakt verwechseln

Englischer technischer Begriff: Artifact vs Image
Priorität: 7/10
Warum wichtig: Maven erzeugt Artefakte; Container Images sind eigene Lieferobjekte.
Typischer Fehler: Jar-Version und Image-Tag laufen auseinander.
Enterprise-Einordnung: Wichtig fuer Kubernetes/OpenShift.
Konfigurationsbeispiel
<properties>
  <image.name>registry.acme.local/commerce/order-service</image.name>
  <image.tag>${project.version}</image.tag>
</properties>
13. Reproduzierbare Builds und CI/CD 12 Einträge

mvn164: Maven Wrapper einchecken

Englischer technischer Begriff: Maven Wrapper
Priorität: 9/10
Warum wichtig: Der Wrapper fixiert die Maven-Version fuer Entwickler und CI.
Typischer Fehler: Jeder nutzt eine andere lokale Maven-Version.
Enterprise-Einordnung: Verbessert Reproduzierbarkeit.
Konfigurationsbeispiel
./mvnw -B -ntp clean verify

mvn165: maven.config fuer Standardflags nutzen

Englischer technischer Begriff: Maven Config File
Priorität: 7/10
Warum wichtig: `.mvn/maven.config` haelt wiederkehrende Flags zentral.
Typischer Fehler: CI- und Entwicklerkommandos unterscheiden sich stark.
Enterprise-Einordnung: Gut fuer Batch, no-transfer-progress und Repo-Pfad.
Konfigurationsbeispiel
-B
-ntp
-Dstyle.color=always

mvn166: jvm.config fuer Maven-JVM begrenzen

Englischer technischer Begriff: Maven JVM Config
Priorität: 6/10
Warum wichtig: `.mvn/jvm.config` steuert Speicher und JVM-Optionen fuer Maven selbst.
Typischer Fehler: Build bricht lokal mit OutOfMemory oder nutzt zu viel Speicher in CI.
Enterprise-Einordnung: Wichtig bei grossen Reactors.
Konfigurationsbeispiel
-Xmx2g
-Dfile.encoding=UTF-8
-Duser.timezone=UTC

mvn167: Builds mit -B und -ntp ausfuehren

Englischer technischer Begriff: CI Maven Flags
Priorität: 8/10
Warum wichtig: Batch und no-transfer-progress machen Logs stabiler.
Typischer Fehler: Pipeline-Logs bestehen aus Download-Fortschritt.
Enterprise-Einordnung: Standard fuer CI.
Konfigurationsbeispiel
mvn -B -ntp clean verify

mvn168: Lokales Repository cachen, aber isolieren

Englischer technischer Begriff: CI Cache Discipline
Priorität: 7/10
Warum wichtig: Cache spart Zeit, isolierter Pfad verhindert Seiteneffekte.
Typischer Fehler: Ein fehlerhaftes Artefakt bleibt fuer alle Jobs im Cache.
Enterprise-Einordnung: Balance zwischen Performance und Reproduzierbarkeit.
Konfigurationsbeispiel
mvn -Dmaven.repo.local=.m2/repository -B -ntp verify

mvn169: Reactor parallel nur nach Teststabilitaet

Englischer technischer Begriff: Parallel Maven Build
Priorität: 6/10
Warum wichtig: -T beschleunigt, kann aber Race Conditions in Tests zeigen.
Typischer Fehler: Flaky Tests entstehen durch gemeinsame Ports oder Dateien.
Enterprise-Einordnung: Erst nach Isolierung aktivieren.
Konfigurationsbeispiel
mvn -T 1C -B -ntp verify

mvn170: Releases mit festem Timestamp bauen

Englischer technischer Begriff: Build Timestamp Stability
Priorität: 8/10
Warum wichtig: Stabile Timestamps erzeugen vergleichbare Artefakte.
Typischer Fehler: Checksums unterscheiden sich ohne Source-Aenderung.
Enterprise-Einordnung: Wichtig fuer Audit und Supply Chain.
Konfigurationsbeispiel
<properties>
  <project.build.outputTimestamp>${env.SOURCE_DATE_EPOCH}</project.build.outputTimestamp>
</properties>

mvn171: Versionsaenderungen automatisieren

Englischer technischer Begriff: Automated Version Set
Priorität: 7/10
Warum wichtig: Versionsupdates sollten reproduzierbar per Tool laufen.
Typischer Fehler: Manuelle Versionserhoehung vergisst Module.
Enterprise-Einordnung: Wichtig fuer grosse Multi-Module-Releases.
Konfigurationsbeispiel
mvn versions:set -DnewVersion=1.13.0-SNAPSHOT -DprocessAllModules=true
mvn versions:commit

mvn172: Effective POM in CI archivieren

Englischer technischer Begriff: Effective POM Evidence
Priorität: 6/10
Warum wichtig: Das effective POM zeigt die tatsaechlich wirksame Konfiguration.
Typischer Fehler: Fehler werden im Parent/Profil gesucht, obwohl ein Child ueberschreibt.
Enterprise-Einordnung: Hilft bei Build-Forensik.
Konfigurationsbeispiel
mvn help:effective-pom -Doutput=target/effective-pom.xml

mvn173: Effective Settings bei Repo-Problemen pruefen

Englischer technischer Begriff: Effective Settings
Priorität: 6/10
Warum wichtig: Effective Settings zeigt aktive Mirrors, Profile und Server-IDs.
Typischer Fehler: 401/404 bei Repository-Aufloesung wird blind debuggt.
Enterprise-Einordnung: Nuetzlich fuer Plattformteams.
Konfigurationsbeispiel
mvn help:effective-settings -Doutput=target/effective-settings.xml

mvn174: go-offline fuer Air-Gapped Builds vorbereiten

Englischer technischer Begriff: Go Offline Preparation
Priorität: 7/10
Warum wichtig: go-offline laedt benoetigte Artefakte vorab.
Typischer Fehler: Air-gapped Pipeline scheitert erst im verify.
Enterprise-Einordnung: Wichtig fuer eingeschraenkte Netzwerke.
Konfigurationsbeispiel
mvn -B dependency:go-offline
mvn -B -o verify

mvn175: Build-Cache nicht mit Release-Sicherheit verwechseln

Englischer technischer Begriff: Cache Safety
Priorität: 6/10
Warum wichtig: Caches beschleunigen, ersetzen aber keine reproduzierbare Aufloesung.
Typischer Fehler: Cache enthaelt alte Snapshots und verdeckt Repository-Probleme.
Enterprise-Einordnung: Wichtig fuer stabile Pipeline-Strategie.
Konfigurationsbeispiel
rm -rf .m2/repository/com/acme/problematic-artifact
mvn -U -B verify
14. Security, Compliance und Supply Chain 16 Einträge

mvn176: SBOM im Build erzeugen

Englischer technischer Begriff: Software Bill of Materials
Priorität: 10/10
Warum wichtig: Eine SBOM listet Dependencies und Artefakte fuer Security und Compliance.
Typischer Fehler: Bei CVE-Frage ist unklar, welche Versionen ausgeliefert wurden.
Enterprise-Einordnung: Pflichtnah fuer moderne Enterprise-Lieferketten.
Konfigurationsbeispiel
<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <configuration>
    <schemaVersion>1.6</schemaVersion>
    <outputFormat>json</outputFormat>
    <includeBomSerialNumber>true</includeBomSerialNumber>
  </configuration>
</plugin>

mvn177: Dependency-Check als Gate dosieren

Englischer technischer Begriff: Vulnerability Scan Gate
Priorität: 9/10
Warum wichtig: Security-Scans finden bekannte Schwachstellen, brauchen aber gepflegte Ausnahmen.
Typischer Fehler: Builds werden wegen unbewerteter False Positives dauerhaft deaktiviert.
Enterprise-Einordnung: Wichtig fuer Release-Freigaben.
Konfigurationsbeispiel
<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <configuration>
    <failBuildOnCVSS>7.0</failBuildOnCVSS>
    <suppressionFiles>
      <suppressionFile>config/security/dependency-check-suppressions.xml</suppressionFile>
    </suppressionFiles>
  </configuration>
</plugin>

mvn178: Lizenzlisten automatisiert erzeugen

Englischer technischer Begriff: License Report
Priorität: 8/10
Warum wichtig: Lizenzreports unterstuetzen rechtliche Pruefung.
Typischer Fehler: Dependencies werden ohne Lizenzbewertung freigegeben.
Enterprise-Einordnung: Wichtig fuer kommerzielle Software.
Konfigurationsbeispiel
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>license-maven-plugin</artifactId>
  <configuration>
    <includeTransitiveDependencies>true</includeTransitiveDependencies>
    <excludedScopes>test</excludedScopes>
  </configuration>
</plugin>

mvn179: Unsichere Repositories blockieren

Englischer technischer Begriff: Repository Security
Priorität: 10/10
Warum wichtig: HTTP-Repositories oder externe Direktzugriffe sind Supply-Chain-Risiken.
Typischer Fehler: Build zieht Artefakte ueber unverschluesselte URLs.
Enterprise-Einordnung: Kritisch fuer Enterprise Governance.
Konfigurationsbeispiel
<mirror>
  <id>acme-secure-mirror</id>
  <mirrorOf>*</mirrorOf>
  <url>https://repo.acme.local/maven/secure</url>
</mirror>

mvn180: Checksums nicht ignorieren

Englischer technischer Begriff: Checksum Validation
Priorität: 9/10
Warum wichtig: Checksum-Fehler koennen Manipulation oder Korruption anzeigen.
Typischer Fehler: Build laeuft trotz Warnung weiter.
Enterprise-Einordnung: Security- und Stabilitaetsgrundregel.
Konfigurationsbeispiel
<releases>
  <enabled>true</enabled>
  <checksumPolicy>fail</checksumPolicy>
</releases>

mvn181: Signaturen fuer Releases nutzen

Englischer technischer Begriff: Artifact Signing
Priorität: 7/10
Warum wichtig: Signierte Artefakte sind besser pruefbar.
Typischer Fehler: Unsignierte Artefakte werden in fremden Repositories schwer vertrauenswuerdig.
Enterprise-Einordnung: Relevant fuer externe oder regulierte Lieferungen.
Konfigurationsbeispiel
<plugin>
  <artifactId>maven-gpg-plugin</artifactId>
  <executions>
    <execution>
      <id>sign-artifacts</id>
      <phase>verify</phase>
      <goals><goal>sign</goal></goals>
    </execution>
  </executions>
</plugin>

mvn182: Secrets im Build-Log verhindern

Englischer technischer Begriff: Secret Hygiene in Logs
Priorität: 10/10
Warum wichtig: Maven-Logs werden in CI gespeichert und oft breit lesbar.
Typischer Fehler: Token wird per -Drepo.password=... im Log sichtbar.
Enterprise-Einordnung: Kritisch fuer jede Pipeline.
Konfigurationsbeispiel
<settings>
  <servers>
    <server>
      <id>acme-releases</id>
      <username>${env.REPO_USER}</username>
      <password>${env.REPO_TOKEN}</password>
    </server>
  </servers>
</settings>

mvn183: Vendor-Artefakte intern spiegeln

Englischer technischer Begriff: Vendor Artifact Repository
Priorität: 8/10
Warum wichtig: Drittanbieter-Jars sollen kontrolliert im internen Repository liegen.
Typischer Fehler: Jars werden im Git eingecheckt oder von zufaelligen URLs geladen.
Enterprise-Einordnung: Wichtig fuer Audit und Langzeitwartung.
Konfigurationsbeispiel
<dependency>
  <groupId>com.vendor.payment</groupId>
  <artifactId>terminal-sdk</artifactId>
  <version>2.8.1</version>
</dependency>

mvn184: No-Snapshot-Regel fuer Release-Profil

Englischer technischer Begriff: No Snapshot Release Gate
Priorität: 10/10
Warum wichtig: Release-Builds muessen feste Dependencies nutzen.
Typischer Fehler: Ein produktives Artefakt verweist auf veraenderliche Snapshot-Version.
Enterprise-Einordnung: Pflicht fuer Freigabe.
Konfigurationsbeispiel
<profile>
  <id>release</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-enforcer-plugin</artifactId>
        <configuration>
          <rules><requireReleaseDeps/></rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

mvn185: Dependency-Allowlist fuer kritische Plattformen

Englischer technischer Begriff: Dependency Allowlist
Priorität: 7/10
Warum wichtig: Eine Allowlist kann Plattformwildwuchs begrenzen.
Typischer Fehler: Jeder Service bringt eigenes Logging, JSON und HTTP-Stack mit.
Enterprise-Einordnung: Sinnvoll fuer regulierte Plattformen.
Konfigurationsbeispiel
<bannedDependencies>
  <searchTransitive>true</searchTransitive>
  <excludes>
    <exclude>commons-httpclient:commons-httpclient</exclude>
    <exclude>org.apache.httpcomponents:httpclient</exclude>
  </excludes>
  <includes>
    <include>org.apache.httpcomponents.client5:httpclient5</include>
  </includes>
</bannedDependencies>

mvn186: Suppressions versioniert und begruendet halten

Englischer technischer Begriff: Security Suppressions
Priorität: 8/10
Warum wichtig: Ausnahmen muessen nachvollziehbar sein und ein Ablaufdatum haben.
Typischer Fehler: False Positives werden pauschal und dauerhaft ignoriert.
Enterprise-Einordnung: Wichtig fuer Audit.
Konfigurationsbeispiel
<configuration>
  <suppressionFiles>
    <suppressionFile>config/security/dependency-check-suppressions.xml</suppressionFile>
  </suppressionFiles>
</configuration>

mvn187: Build-Inputs nicht aus dem Internet nachladen

Englischer technischer Begriff: No Runtime Downloads in Build
Priorität: 9/10
Warum wichtig: Generatoren sollen Artefakte ueber Maven-Repositories beziehen.
Typischer Fehler: Build-Skript laedt Zip per curl von unversionierter URL.
Enterprise-Einordnung: Supply-Chain-Risiko.
Konfigurationsbeispiel
<dependency>
  <groupId>com.acme.schemas</groupId>
  <artifactId>partner-schema-bundle</artifactId>
  <version>2026.07.0</version>
  <type>zip</type>
</dependency>

mvn188: POM-Dateien reviewbar halten

Englischer technischer Begriff: Reviewable Build Configuration
Priorität: 7/10
Warum wichtig: Build-Konfiguration ist produktionsrelevanter Code.
Typischer Fehler: Aenderungen an Parent-POM passieren ohne Review.
Enterprise-Einordnung: Wichtig fuer Governance.
Konfigurationsbeispiel
<scm>
  <connection>scm:git:ssh://git.acme.local/platform/enterprise-parent.git</connection>
  <tag>enterprise-parent-1.12.0</tag>
</scm>

mvn189: Dependencies fuer CVE-Fixes zentral ueberschreiben

Englischer technischer Begriff: Central CVE Override
Priorität: 9/10
Warum wichtig: Ein zentraler Override patched viele Module gleichzeitig.
Typischer Fehler: Jedes Team reagiert einzeln auf CVEs.
Enterprise-Einordnung: Schnelle Security-Reaktion.
Konfigurationsbeispiel
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>${jackson-databind.secure.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn190: Veraltete Gruppen aktiv verbieten

Englischer technischer Begriff: Deprecated Group Ban
Priorität: 8/10
Warum wichtig: Alte javax/jakarta-Mischungen oder Legacy-Gruppen koennen Migrationen bremsen.
Typischer Fehler: Neue Module ziehen wieder alte Java EE Artefakte.
Enterprise-Einordnung: Hilft bei Modernisierung.
Konfigurationsbeispiel
<bannedDependencies>
  <searchTransitive>true</searchTransitive>
  <excludes>
    <exclude>javax:javaee-api</exclude>
    <exclude>javax.servlet:servlet-api</exclude>
  </excludes>
</bannedDependencies>

mvn191: Audit-Artefakte deploybar machen

Englischer technischer Begriff: Audit Artifact Attachment
Priorität: 7/10
Warum wichtig: SBOM, Dependency Tree und Lizenzreport sollen als Build-Ergebnis erhalten bleiben.
Typischer Fehler: Pruefberichte verschwinden nach CI-Lauf.
Enterprise-Einordnung: Wichtig fuer Nachweise.
Konfigurationsbeispiel
<execution>
  <id>attach-sbom</id>
  <phase>package</phase>
  <goals><goal>attach-artifact</goal></goals>
  <configuration>
    <artifacts>
      <artifact>
        <file>${project.build.directory}/bom.json</file>
        <type>json</type>
        <classifier>cyclonedx</classifier>
      </artifact>
    </artifacts>
  </configuration>
</execution>
15. Diagnose, Effective POM und typische Maven-Kommandos 12 Einträge

mvn192: Effective POM lesen

Englischer technischer Begriff: Effective POM
Priorität: 8/10
Warum wichtig: Zeigt die zusammengefuehrte Sicht aus Parent, Profilen und Defaults.
Typischer Fehler: Man debuggt die falsche POM-Ebene.
Enterprise-Einordnung: Sehr hilfreich bei Parent- und Profilproblemen.
Konfigurationsbeispiel
mvn help:effective-pom -Doutput=target/effective-pom.xml

mvn193: Effective Settings lesen

Englischer technischer Begriff: Effective Settings
Priorität: 7/10
Warum wichtig: Zeigt aktive settings.xml, Profile, Server und Mirrors.
Typischer Fehler: Repositoryfehler werden ohne aktive Mirror-Sicht analysiert.
Enterprise-Einordnung: Wichtig fuer Entwickler- und CI-Diagnose.
Konfigurationsbeispiel
mvn help:effective-settings -Doutput=target/effective-settings.xml

mvn194: Dependency Tree mit Includes eingrenzen

Englischer technischer Begriff: Filtered Dependency Tree
Priorität: 8/10
Warum wichtig: Filter machen grosse Graphen lesbar.
Typischer Fehler: Man durchsucht tausende Zeilen manuell.
Enterprise-Einordnung: Nuetzlich bei CVE und Versionkonflikt.
Konfigurationsbeispiel
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core

mvn195: Dependency Analyze fuer direkte Abhaengigkeiten

Englischer technischer Begriff: Dependency Analyze
Priorität: 7/10
Warum wichtig: Findet genutzte-undeklarierte sowie ungenutzte deklarierte Dependencies.
Typischer Fehler: Code baut wegen transitiver Zufallsdependency.
Enterprise-Einordnung: Verbessert POM-Qualitaet.
Konfigurationsbeispiel
mvn dependency:analyze

mvn196: Plugin-Konfiguration anzeigen

Englischer technischer Begriff: Describe Plugin
Priorität: 6/10
Warum wichtig: describe zeigt Goals und Parameter eines Plugins.
Typischer Fehler: Parameter werden geraten oder aus alten Beispielen kopiert.
Enterprise-Einordnung: Hilft bei sauberer Konfiguration.
Konfigurationsbeispiel
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin -Ddetail

mvn197: Aktive Profile anzeigen

Englischer technischer Begriff: Active Profiles
Priorität: 7/10
Warum wichtig: Zeigt welche Profile wirklich aktiv sind.
Typischer Fehler: Man nimmt an, dass ci aktiv ist, obwohl nur local-defaults laeuft.
Enterprise-Einordnung: Wichtig bei unterschiedlichen lokalen/CI Builds.
Konfigurationsbeispiel
mvn help:active-profiles

mvn198: Projektmodule gezielt listen

Englischer technischer Begriff: Reactor Debug
Priorität: 5/10
Warum wichtig: Eine gezielte Buildauswahl zeigt Reactor-Probleme schneller.
Typischer Fehler: Gesamtbuild verdeckt das eigentliche Modulproblem.
Enterprise-Einordnung: Nuetzlich fuer grosse Repositories.
Konfigurationsbeispiel
mvn -pl services/order-service -am validate

mvn199: Updates kontrolliert anzeigen

Englischer technischer Begriff: Display Updates
Priorität: 6/10
Warum wichtig: Update-Reports helfen bei geplanter Modernisierung.
Typischer Fehler: Dependencies werden blind aktualisiert.
Enterprise-Einordnung: Geeignet fuer technische Schuldenplanung.
Konfigurationsbeispiel
mvn versions:display-dependency-updates
mvn versions:display-plugin-updates

mvn200: Snapshots gezielt aktualisieren

Englischer technischer Begriff: Update Snapshots
Priorität: 6/10
Warum wichtig: -U zwingt Snapshot- und Metadaten-Update.
Typischer Fehler: Build verwendet alten Snapshot und Fehler ist scheinbar nicht behoben.
Enterprise-Einordnung: Nuetzlich im Integrationsumfeld.
Konfigurationsbeispiel
mvn -U -B verify

mvn201: Fehler mit Stacktrace analysieren

Englischer technischer Begriff: Maven Error Detail
Priorität: 5/10
Warum wichtig: -e und -X liefern Details, aber sehr viel Log.
Typischer Fehler: Man aktiviert -X dauerhaft in CI und erzeugt unlesbare Logs.
Enterprise-Einordnung: Gezielt fuer Debugging.
Konfigurationsbeispiel
mvn -e verify
mvn -X -pl services/billing-service test

mvn202: Nur Tests eines Moduls laufen lassen

Englischer technischer Begriff: Targeted Test Run
Priorität: 6/10
Warum wichtig: Gezielte Testlaeufe beschleunigen Entwicklung.
Typischer Fehler: Entwickler starten permanent den Gesamtbuild.
Enterprise-Einordnung: Produktiver Alltag in Multi-Modulen.
Konfigurationsbeispiel
mvn -pl services/order-service -Dtest=OrderPriceCalculatorTest test

mvn203: Integrationstest gezielt starten

Englischer technischer Begriff: Targeted IT Run
Priorität: 6/10
Warum wichtig: Einzelne ITs helfen beim Debugging von Schnittstellen.
Typischer Fehler: Alle ITs laufen fuer jede kleine Aenderung.
Enterprise-Einordnung: Praktisch bei Datenbank und Messaging.
Konfigurationsbeispiel
mvn -pl services/order-service -Dit.test=OrderRepositoryIT verify