Maven Teil 2: Dependency Hell beenden – Wenn deine App 47 Dependencies hat und nichts mehr geht

Von Elyndra Valen, Senior Entwicklerin & Code-Archäologin bei Java Fleet Systems Consulting

📚 Was du bisher gelernt hast

In Teil 1 hast du gelernt:

  • ✅ Eine POM.xml zu lesen ohne Panik
  • ✅ Parent POMs und Vererbung zu verstehen
  • ✅ Properties sinnvoll einzusetzen

Heute lösen wir dein größtes Problem:

  • ❌ Deine App wirft NoSuchMethodError
  • ❌ Du hast 47 Dependencies und weißt nicht mehr welche Version was macht
  • ❌ Drei verschiedene Jackson-Versionen kämpfen um die Vorherrschaft

Willkommen in der Dependency Hell. Lass uns dich da rausholen! 🔥

⚡ Was du in den nächsten 12 Minuten lernst

Nach diesem Beitrag kannst du:

  • ✅ Versionskonflikte finden UND lösen
  • ✅ Maven Scopes richtig einsetzen (besonders das tricky provided!)
  • ✅ dependencyManagement als deine zentrale Versionskontrolle nutzen
  • ✅ Verstehen, warum Maven manchmal die „falsche“ Version lädt

Dein größter Gewinn heute: Nie wieder NoSuchMethodError wegen Version-Chaos!

Lesezeit: 12 Minuten | Mit Übungen: 30 Minuten

Hi! 👋

Elyndra hier. Schön, dass du wieder dabei bist!

Erinnerst du dich? In Teil 1 haben wir die POM-Anatomie erforscht. Seitdem haben mir Anna aus München, Stefan aus Hamburg und Sarah geschrieben – alle mit demselben Problem: NoSuchMethodError nach dem Hinzufügen einer „harmlosen“ Dependency.

Und weißt du was? Ich kenne das Problem. Gestern Abend saß ich selbst bis spät über altem Legacy-Code – 47 Dependencies, drei verschiedene Jackson-Versionen. Das erinnerte mich an Marcus und seine Renovierungsprojekte: Manchmal muss man erst mal alles auseinandernehmen, um zu verstehen, wie es wirklich zusammenpasst. Bei alten Balken ist das einfacher als bei verrosteten Dependencies… aber ich schweife ab.

Lass uns heute gemeinsam deine Dependency Hell aufräumen! 🔧

🎯 Das klassische Dependency-Szenario

Stell dir vor, es ist Montag, 9:15 Uhr. Du hast nur Spring Security zu deiner App hinzugefügt – und plötzlich ist ALLES kaputt! 😭

Deine pom.xml sieht etwa so aus:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.7.0</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-core</artifactId>
        <version>6.0.0</version> <!-- 🚨 PROBLEM! -->
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.11.0</version>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-core</artifactId>
        <!-- Keine Version! Maven "rät" -->
    </dependency>
</dependencies>

Der Fehler:

java.lang.NoSuchMethodError: 
  com.fasterxml.jackson.databind.ObjectMapper.readValue(Ljava/lang/String;)

Deine Reaktion: „Aber ich hab doch Jackson drin?!“

Die Wahrheit: Ja, aber WELCHES Jackson? Lass uns nachschauen…

🔍 Dependencies vs. Plugins – Der wichtige Unterschied

Bevor wir weitermachen: Du musst diesen Unterschied verstehen!

Dependencies = Code, den deine App zur LAUFZEIT braucht
Plugins = Tools, die Maven beim BAUEN nutzt

<!-- DEPENDENCY: Wird Teil deiner App -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- PLUGIN: Nur für den Build-Prozess -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
</plugin>

Häufiger Fehler (den Sarah letzte Woche machte):
Sie hatte den Compiler als Dependency eingefügt!

<!-- 🚫 FALSCH! Compiler ist KEIN Runtime-Code -->
<dependency>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
</dependency>

Deine Faustregel: Wenn deine App es zur Laufzeit nicht braucht → Plugin, nicht Dependency!

🎭 Maven Scopes erklärt – Wann wird was geladen?

Stell dir Scopes wie verschiedene Schubladen in deinem Werkzeugkasten vor. Manche Werkzeuge brauchst du immer (compile), manche nur beim Testen (test), und manche stellt dir die Werkstatt zur Verfügung (provided).

Die 6 Scopes (nur 4 sind wirklich wichtig)

1. compile (Default) – „Ich brauche das immer“

Was bedeutet compile wirklich?
Wenn du keinen Scope angibst, nimmt Maven automatisch compile. Diese Dependencies sind wie dein Hauptwerkzeug – du brauchst sie ÜBERALL: beim Entwickeln, beim Testen und wenn deine App läuft.

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <scope>compile</scope> <!-- Kann weggelassen werden -->
</dependency>

Was passiert im Detail:

✅ Compile-Time: Dein Code kann import org.springframework.* nutzen
✅ Test-Time: Deine Tests sehen diese Klassen auch
✅ Runtime: Die JAR wird in dein finales Paket eingebunden
✅ Transitiv: Andere Projekte, die dein Projekt nutzen, bekommen diese Dependency auch

Praktisches Beispiel: Spring Core enthält die Basis-Funktionen von Spring. Dein Code nutzt Annotations wie @Component, die aus diesem JAR kommen. Ohne spring-core würde dein Code nicht mal kompilieren!

2. test – „Nur für Tests“

Was bedeutet test wirklich?
Test-Dependencies sind wie Spezialwerkzeuge, die du nur in der Qualitätskontrolle brauchst. Sie werden NIEMALS mit deiner App ausgeliefert.

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <scope>test</scope>
</dependency>

Was passiert im Detail:

❌ Compile-Time: Dein Produktiv-Code kennt JUnit nicht
✅ Test-Time: Nur Klassen in src/test/java können JUnit importieren
❌ Runtime: JUnit ist NICHT in deiner WAR/JAR
❌ Package-Size: Spart Megabytes in deinem Deployment!

Stefan aus Hamburg schrieb mir letzte Woche: Er hatte JUnit ohne Scope – es landete in Production! 5MB verschwendet für nichts!

3. provided – „Jemand anders stellt das bereit“

Was bedeutet provided wirklich?
Stell dir vor, du entwickelst in einer Firma, wo bestimmte Tools schon vorhanden sind. Du musst wissen, wie du sie benutzt (compile), aber du musst sie nicht mitbringen (runtime), weil sie schon da sind!

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <scope>provided</scope>
</dependency>

Was passiert im Detail:

✅ Compile-Time: Dein Code kann HttpServletRequest nutzen
✅ Test-Time: Tests können Servlet-Mocks verwenden
❌ Runtime: Die JAR ist NICHT in deiner WAR-Datei
⚡ Warum? Der Application Server (Tomcat, JBoss) hat servlet-api schon!

Klassisches Beispiel – Application Server:
Wenn du eine WAR für Tomcat baust, hat Tomcat schon servlet-api.jar in seinem lib Ordner. Würdest du es nochmal mitliefern, gibt’s ClassLoader-Konflikte!

Annas häufiger Fehler:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <scope>provided</scope> <!-- FALSCH für Spring Boot! -->
</dependency>

Warum falsch? Spring Boot ist KEIN Application Server! Lombok wird zur Compile-Zeit gebraucht, aber zur Laufzeit nicht. Richtig wäre: ohne Scope (compile) oder mit optional=true.

4. runtime – „Brauche ich nur zur Laufzeit“

Was bedeutet runtime wirklich?
Runtime-Dependencies sind wie Treiber – dein Code weiß nicht, welche Marke, aber zur Laufzeit muss einer da sein!

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <scope>runtime</scope>
</dependency>

Was passiert im Detail:

❌ Compile-Time: Kein import com.mysql.* möglich!
✅ Test-Time: Tests können die DB nutzen (über JDBC)
✅ Runtime: Der Treiber ist in deiner JAR
🎯 Warum? Dein Code nutzt nur java.sql.* Interfaces!

Praktisches Beispiel:

// Dein Code kennt nur JDBC-Interfaces:
Connection conn = DriverManager.getConnection(
    "jdbc:mysql://localhost:3306/db", "user", "pass"
);
// MySQL-Treiber wird zur Laufzeit über Reflection geladen!

Der Vorteil: Du kannst zwischen MySQL, PostgreSQL, H2 wechseln, ohne deinen Code neu zu kompilieren!

🌳 Transitive Dependencies – Die versteckten Mitreisenden

Was du vielleicht nicht wusstest: Jede Dependency bringt eigene Dependencies mit!

Lass uns nachschauen, was du wirklich in deinem Projekt hast:

mvn dependency:tree

Output (gekürzt):

[INFO] de.javafleet:taskmanager:jar:1.0.0
[INFO] +- org.springframework.boot:spring-boot-starter-web:2.7.0
[INFO] |  +- org.springframework:spring-core:5.3.20  
[INFO] |  +- org.springframework:spring-web:5.3.20
[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:2.13.3 <!-- Version 1 -->
[INFO] |  \- ...
[INFO] +- com.fasterxml.jackson.core:jackson-databind:2.11.0 <!-- Version 2! -->

Das Problem: Zwei verschiedene Jackson-Versionen! Maven wählt eine (nicht immer die richtige).

Die Dependency-Analyse Tools

# Zeigt den kompletten Baum
mvn dependency:tree

# Zeigt nur Konflikte
mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core

# Analysiert ungenutzte Dependencies
mvn dependency:analyze

Sarahs Reaktion letzte Woche: „Es gibt TOOLS dafür?! Ich hab 2 Stunden manuell gesucht!“ 🤦‍♀️

Ja, Sarah, es gibt Tools. Und heute lernst du, sie zu nutzen!

💊 dependencyManagement – Die Heilung für Version-Chaos

Stell dir vor, du hast 5 Module in deinem Projekt. Jedes nutzt Jackson. Willst du wirklich in JEDEM Modul die Version pflegen? Was passiert, wenn du eine aktualisierst und die anderen vergisst? Genau – Chaos!

dependencyManagement ist wie eine zentrale Versionsverwaltung für dein ganzes Projekt.

Das Problem ohne dependencyManagement – Dein reales Szenario

Stell dir ein Projekt mit 3 Modulen vor – API, Service, Database:

<!-- modul-api/pom.xml -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.12.0</version> <!-- Version 1 -->
</dependency>

<!-- modul-service/pom.xml -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.13.0</version> <!-- Version 2 - anders! -->
</dependency>

<!-- modul-database/pom.xml -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.11.0</version> <!-- Version 3 - noch älter! -->
</dependency>

Was passiert beim Build? Maven muss EINE Version wählen. Die Regeln:

  1. Nearest Definition: Die Version, die „näher“ am aktuellen POM ist
  2. First Declaration: Bei gleicher Entfernung: wer zuerst kommt

Das Ergebnis: Unterschiedliche Jackson-Versionen je nach Build-Reihenfolge! 💥

Die Lösung: Zentrale Versionsverwaltung mit dependencyManagement

Im Parent-POM (oder Haupt-POM):

<project>
    <!-- ... andere Konfiguration ... -->
    
    <dependencyManagement>
        <dependencies>
            <!-- Hier definierst du ALLE Versionen ZENTRAL -->
            <dependency>
                <groupId>com.fasterxml.jackson.core</groupId>
                <artifactId>jackson-databind</artifactId>
                <version>2.13.3</version>
            </dependency>
            
            <dependency>
                <groupId>com.fasterxml.jackson.core</groupId>
                <artifactId>jackson-core</artifactId>
                <version>2.13.3</version> <!-- Gleiche Version! -->
            </dependency>
            
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>1.7.36</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

In den Modulen – KEINE Version mehr!

<!-- modul-api/pom.xml -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <!-- KEINE VERSION! Kommt vom Parent -->
</dependency>

<!-- modul-service/pom.xml -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <!-- Auch hier: KEINE VERSION! -->
</dependency>

Der geniale Trick: Spring Boot Dependencies importieren

Anstatt hunderte Versionen selbst zu managen:

<dependencyManagement>
    <dependencies>
        <!-- Importiere ALLE Spring Boot Versionen auf einmal! -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.7.0</version>
            <type>pom</type>
            <scope>import</scope> <!-- IMPORT ist der Trick! -->
        </dependency>
    </dependencies>
</dependencyManagement>

Was passiert hier?

  • type=pom: Sagt Maven „Das ist kein JAR, sondern eine POM mit Versionen“
  • scope=import: „Importiere alle dependencyManagement Einträge von Spring Boot“
  • Ergebnis: Du bekommst kompatible Versionen von 100+ Libraries!

Deine Reaktion: „Warte, Spring Boot managed für mich Jackson, JUnit, Mockito, alles?!“
Meine Antwort: „Genau! Und alle Versionen sind getestet und funktionieren zusammen!“

🏪 Repository-Konfiguration – Woher kommen die JARs?

Maven ist wie ein Paket-Lieferservice. Repositories sind die Lagerhäuser, wo die Pakete (JARs) liegen. Maven schaut standardmäßig in Maven Central – dem „Amazon“ der Java-Welt. Aber manchmal brauchst du spezielle Läden!

Die Repository-Hierarchie: Wo Maven sucht

Die Such-Reihenfolge:

  1. Local Repository (~/.m2/repository) – Dein persönlicher Cache
  2. Configured Repositories – Was du in der POM definierst
  3. Maven Central – Der Standard-Shop für Open Source

Standard: Maven Central – Der große Marktplatz

<!-- Das ist implizit IMMER da, musst du nicht hinzufügen -->
<repository>
    <id>central</id>
    <name>Maven Central Repository</name>
    <url>https://repo.maven.apache.org/maven2</url>
    <layout>default</layout>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled> <!-- Central hat keine SNAPSHOTs! -->
    </snapshots>
</repository>

Was ist Maven Central?

  • Größe: Über 8 Millionen Artifacts!
  • Inhalt: Alle großen Open-Source-Projekte (Spring, Apache, Google…)
  • Garantie: Einmal hochgeladen, für immer verfügbar
  • Sicherheit: Signierte JARs, Checksums, keine Malware

Firmen-Repository (Nexus/Artifactory) – Der private Shop

<repositories>
    <repository>
        <id>company-nexus</id>
        <name>Firmen Nexus Repository</name>
        <url>http://nexus.firma.local:8081/repository/maven-public/</url>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </releases>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
    </repository>
</repositories>

Warum ein Firmen-Repository?

  • Proxy: Cached externe Dependencies (spart Bandbreite)
  • Eigene JARs: Interne Libraries, die nicht public sind
  • Sicherheit: Scannt JARs auf Vulnerabilities
  • Kontrolle: Bestimme, welche Libraries erlaubt sind

Annas Frage letzte Woche: „Warum kann ich manche Sachen nicht von zu Hause laden?“
Meine Antwort: „Das Firmen-Repo ist nur im Firmennetz erreichbar! VPN anmachen!“

Spezielle Repositories – Die Boutiquen

Oracle Maven Repository (für Oracle JDBC Driver):

<repository>
    <id>maven.oracle.com</id>
    <name>Oracle Maven Repository</name>
    <url>https://maven.oracle.com</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Spring Milestone Repository (für Preview-Versionen):

<repository>
    <id>spring-milestone</id>
    <name>Spring Milestone Repository</name>
    <url>https://repo.spring.io/milestone</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Repository-Settings im Detail erklärt

<repository>
    <id>my-repo</id> <!-- Eindeutige ID, wichtig für settings.xml -->
    <name>Beschreibender Name</name>
    <url>https://repo.example.com/maven2</url>
    
    <releases>
        <enabled>true</enabled>
        <updatePolicy>daily</updatePolicy> <!-- daily, always, never, interval:X -->
        <checksumPolicy>warn</checksumPolicy> <!-- fail, warn, ignore -->
    </releases>
    
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>always</updatePolicy> <!-- SNAPSHOTs ändern sich oft! -->
        <checksumPolicy>fail</checksumPolicy> <!-- Strenger bei SNAPSHOTs -->
    </snapshots>
    
    <layout>default</layout> <!-- Maven 2 Layout, nie ändern -->
</repository>

updatePolicy erklärt:

  • always: Prüfe bei JEDEM Build
  • daily: Einmal am Tag (default)
  • never: Nur beim ersten Download
  • interval:30: Alle 30 Minuten

checksumPolicy erklärt:

  • fail: Build bricht ab bei falscher Checksum (Sicherheit!)
  • warn: Nur Warnung ausgeben
  • ignore: Checksums ignorieren (GEFÄHRLICH!)

Authentication für private Repositories

In der ~/.m2/settings.xml (NICHT in der POM!):

<settings>
    <servers>
        <server>
            <id>company-nexus</id> <!-- Muss zur Repository-ID passen! -->
            <username>dein.name</username>
            <password>{verschlüsseltes-passwort}</password>
        </server>
    </servers>
</settings>

Stefans Fehler: „Ich hab Username/Password in die POM geschrieben!“
Meine Warnung: „NIEMALS! Die POM wird eingecheckt. Credentials gehören in settings.xml!“

🔧 Dein Dependency-Problem lösen – Schritt für Schritt

Lass uns jetzt dein konkretes Problem von oben lösen!

Schritt 1: Analyse

mvn dependency:tree -Dverbose | grep jackson

Dein Ergebnis: 3 verschiedene Jackson-Versionen! 😱

Schritt 2: dependencyManagement einführen

<dependencyManagement>
    <dependencies>
        <!-- Spring Boot Parent übernimmt Versions-Management -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.7.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Schritt 3: Dependencies ohne Versionen

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <!-- Keine Version! Spring Boot managed das -->
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
        <!-- Kompatible Version automatisch! -->
    </dependency>
</dependencies>

Schritt 4: Clean Build

mvn clean install

Deine Reaktion: „ES FUNKTIONIERT! Keine Errors mehr!“ 🎉

💡 Pro-Tipps aus der Praxis

1. SNAPSHOT vs RELEASE verstehen

<!-- SNAPSHOT = Development Version, ändert sich -->
<version>1.0.0-SNAPSHOT</version>

<!-- RELEASE = Stabile Version, ändert sich NIE -->
<version>1.0.0</version>

Deine Regel: Nutze NIEMALS SNAPSHOTs in Production!

2. Version Ranges (mit Vorsicht!)

<!-- Nimm irgendwas zwischen 2.0 und 3.0 -->
<version>[2.0,3.0)</version>

<!-- Mindestens 2.7.0 -->
<version>[2.7.0,)</version>

Meine Meinung: Lass es! Explizite Versionen sind sicherer.

3. Exclude unerwünschte Transitive Dependencies

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>

4. Der „Enforcer“ – Dependency-Polizei

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <executions>
        <execution>
            <id>enforce</id>
            <goals><goal>enforce</goal></goals>
            <configuration>
                <rules>
                    <dependencyConvergence/> <!-- Keine Versionskonflikte! -->
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

🏆 Von Chaos zu Kontrolle

Deine Transformation diese Woche:

Vorher: „Ich füge Dependencies hinzu bis es funktioniert“
Nachher: „Ich verstehe, was ich hinzufüge und warum“

Die wichtigsten Learnings:

✅ dependency:tree ist dein Freund – nutze es BEVOR Probleme auftreten
✅ dependencyManagement für konsistente Versionen
✅ Spring Boot Parent macht vieles automatisch richtig
✅ Scopes verstehen spart Deployment-Probleme

Übrigens kam Kofi gestern zu mir: „Ihr solltet wissen, dass Maven’s Dependency Resolution Algorithm ein NP-vollständiges Problem löst…“

Ich: „Kofi, not now. Wir müssen erst mal verstehen, WIE es funktioniert, nicht WARUM es mathematisch komplex ist.“ 🙄

(Manchmal ist es wie mit Marcus und seinen Renovierungsprojekten – die Theorie ist schön, aber praktisch muss man erst mal die alten Balken austauschen, bevor man über Statik philosophiert…)

🗓️ Nächste Woche: Build-Lifecycle & Profiles

Vorschau auf Teil 3:

Deine nächste Challenge: „Warum läuft es auf meinem Rechner aber nicht auf dem Server?“

Du lernst:

  • Maven Build-Lifecycle verstehen
  • Profile für verschiedene Umgebungen
  • Properties und Filtering
  • „Works on my machine“ für immer beenden!

❓ FAQ – Dependency Edition

Frage 1: Warum lädt Maven manchmal alte Versionen obwohl ich neue angebe?
Antwort: Maven’s „nearest definition wins“ Regel! Die Version, die am nächsten an deinem Projekt definiert ist, gewinnt. Nutze dependency:tree -Dverbose um zu sehen, welche Version warum gewählt wurde.

Frage 2: Kann ich lokale JARs als Dependencies nutzen?
Antwort: Ja, aber solltest du nicht! Besser: Installiere sie in dein lokales Repository mit mvn install:install-file oder noch besser: Lade sie in ein Firmen-Repository hoch.

Frage 3: Was ist der Unterschied zwischen compile und runtime scope?
Antwort: compile = Code kennt die Klassen (z.B. import statements). runtime = Code kennt Klassen nicht, braucht sie aber zur Laufzeit (z.B. JDBC-Treiber).

Frage 4: Wie finde ich ungenutzte Dependencies?
Antwort: mvn dependency:analyze zeigt dir „Unused declared dependencies“ – aber Vorsicht! Manchmal werden Dependencies nur via Reflection genutzt.

Frage 5: Warum sollte ich Spring Boot’s dependency Management nutzen?
Antwort: Spring testet alle Versionen zusammen! Du bekommst garantiert kompatible Versionen von 100+ Libraries. Das spart STUNDEN an Debugging!

Frage 6: Was mache ich bei „Cannot resolve dependency“ Fehlern?
Antwort: Check: 1) Schreibfehler? 2) Repository erreichbar? 3) Proxy-Settings? 4) .m2/repository löschen und neu laden. 5) mvn -U für Update-Check.

Frage 7: Wie geht ihr mit Konflikten zwischen Dependencies um?
Antwort: Dependencies haben wir meist im Griff… aber manchmal gibt’s andere Konflikte im Leben, die schwieriger zu lösen sind. Manche Geschichten passen nicht in einen Tech-Blog. Aber das ist wirklich ein anderes Thema – vielleicht findest du mehr darüber, wenn du nach „Herz Schmerz“ suchst. Oder besser: lass uns beim Code bleiben. 😉

✅ Deine Lern-Checkliste

Nach diesem Beitrag kannst du:

  • [ ] mvn dependency:tree ausführen und verstehen
  • [ ] Scopes richtig zuordnen (compile, test, provided, runtime)
  • [ ] dependencyManagement in einem Parent-POM einrichten
  • [ ] Spring Boot Dependencies importieren mit scope=import
  • [ ] Transitive Dependencies analysieren
  • [ ] Version-Konflikte identifizieren und lösen
  • [ ] Repositories konfigurieren
  • [ ] Den Unterschied zwischen Dependencies und Plugins erklären

Teste dich selbst: Öffne dein aktuelles Projekt und führe mvn dependency:tree aus. Findest du Versionskonflikte? Probiere dependencyManagement aus!

📚 Die komplette Maven-Serie

Bereits veröffentlicht:

✅ Teil 1 : POM.xml entmystifiziert – Von null auf lauffähig
✅ Teil 2: Dependency Hell beenden ← Du bist hier!

Kommende Teile:

📅 Teil 3 (08.10.2025): Build-Lifecycle & Profiles – Works on my machine war gestern
📅 Teil 4 (15.10.2025): Plugin-Ökosystem – Die mächtigen Helfer
📅 Teil 5 (22.10.2025): Maven meets AI – Moderne Workflows

🎯 Abschluss

Das war Teil 2 der Maven-Serie! Du hast heute gelernt, dass Dependencies nicht „Magie“ sind, sondern ein lösbares Puzzle.

Deine nächsten Schritte:

  1. Führe mvn dependency:tree in deinem Projekt aus
  2. Schau dir die Versionen genau an
  3. Probiere dependencyManagement aus
  4. Schreib mir, wenn du Fragen hast!

Anna, Stefan, Sarah – danke für eure Fragen diese Woche. Ihr habt diesen Artikel inspiriert!

Und an alle, die mitlesen: Habt ihr ähnliche Dependency-Probleme gehabt? Schreibt mir! Eure Fragen werden zu den nächsten Artikeln.

Keep coding, keep learning! 🚀

P.S.: Übrigens, falls du mal neugierig bist, was hinter den Kulissen passiert… manchmal schreiben wir über mehr als nur Code. Aber solche Geschichten findest du nicht hier im Tech-Blog. Die verstecken sich woanders… in den geheimen logs sozusagen. 😏

Folge Elyndras Maven-Grundlagen jeden Dienstag hier im Blog.
Nächste Woche: Warum „works on my machine“ keine Ausrede mehr ist!

#Maven #Dependencies #JavaDevelopment #SpringBoot #DependencyHell #LearningTogether

Autor

  • Elyndra Valen

    28 Jahre alt, wurde kürzlich zur Senior Entwicklerin befördert nach 4 Jahren intensiver Java-Entwicklung. Elyndra kennt die wichtigsten Frameworks und Patterns, beginnt aber gerade erst, die tieferen Zusammenhänge und Architektur-Entscheidungen zu verstehen. Sie ist die Brücke zwischen Junior- und Senior-Welt im Team.

Tags:

Dependency HellDependency ManagementJavaMaven
← Vorheriger Artikel GraalVM Teil 4: Zusammenfassung Java-Swing → Native Image (macOS, Linux, Windows)
Nächster Artikel → Teil 1: Lambda-Archäologie – Warum LISP die Zukunft von Java ist und was ist das Lambda-Kalkül?