{"id":1911,"date":"2025-02-12T09:17:27","date_gmt":"2025-02-12T01:17:27","guid":{"rendered":"https:\/\/www.fanyamin.com\/wordpress\/?p=1911"},"modified":"2025-02-12T09:17:27","modified_gmt":"2025-02-12T01:17:27","slug":"solve-the-dependency-hell-by-maven","status":"publish","type":"post","link":"https:\/\/www.fanyamin.com\/wordpress\/?p=1911","title":{"rendered":"Solve the dependency hell by maven"},"content":{"rendered":"

Resolving version conflicts in Maven can be tricky, but Maven provides several strategies and mechanisms to handle dependency conflicts effectively. Here\u2019s a deeper dive into how you can resolve version conflicts in Maven:<\/p>\n

1. Maven's Dependency Mediation (Nearest-Wins Strategy)<\/strong><\/h3>\n

Maven uses a nearest-wins<\/strong> strategy to resolve version conflicts. This means that when multiple versions of the same dependency are found in the dependency tree, Maven will pick the version that is closest<\/strong> to the project in terms of the dependency hierarchy.<\/p>\n

Example:<\/h4>\n

Suppose you have two dependencies in your project:<\/p>\n

    \n
  • Library A<\/strong> depends on version 1.0 of libX<\/code>.<\/li>\n
  • Library B<\/strong> depends on version 2.0 of libX<\/code>.<\/li>\n<\/ul>\n

    If both Library A<\/code> and Library B<\/code> are in the same project, Maven will pick libX version 2.0<\/strong> if it's the version that appears closest to your project in the dependency hierarchy.<\/p>\n

    This is because Maven considers the direct dependencies<\/strong> first and chooses the one closer to your project.<\/p>\n

    How to Fix:<\/h4>\n

    If you need to enforce a particular version, you can explicitly specify the version in your dependencyManagement<\/strong> section (see below) or override it using dependency exclusions<\/strong>.<\/p>\n

    2. Using <dependencyManagement><\/code> for Centralized Version Control<\/strong><\/h3>\n

    Maven provides a <dependencyManagement><\/code> section, where you can specify versions for all your dependencies in one place. This allows you to ensure that all submodules or transitive dependencies use the same version of a dependency.<\/p>\n

    Example:<\/h4>\n

    You have a multi-module project or you want to ensure consistency across different parts of your application.<\/p>\n

    <dependencyManagement>\n    <dependencies>\n        <!-- Define the version of libX -->\n        <dependency>\n            <groupId>com.example<\/groupId>\n            <artifactId>libX<\/artifactId>\n            <version>2.0<\/version>\n        <\/dependency>\n    <\/dependencies>\n<\/dependencyManagement><\/code><\/pre>\n
    This ensures that libX<\/strong> version 2.0 is used consistently across the entire project, even if other libraries bring in different versions of libX<\/code> as transitive dependencies.<\/p>\n
    3. Excluding Transitive Dependencies<\/strong><\/h3>\n
    Sometimes, dependencies you include may bring in conflicting versions of libraries you don't need. In such cases, you can exclude<\/strong> those transitive dependencies from being included in your project.<\/p>\n
    Example:<\/h4>\n
    Suppose Library A<\/strong> depends on libX<\/code> version 1.0, but you want to use version 2.0. You can exclude version 1.0 from Library A<\/code>.<\/p>\n
    <dependency>\n    <groupId>com.example<\/groupId>\n    <artifactId>libraryA<\/artifactId>\n    <version>1.0<\/version>\n    <exclusions>\n        <exclusion>\n            <groupId>com.example<\/groupId>\n            <artifactId>libX<\/artifactId>\n        <\/exclusion>\n    <\/exclusions>\n<\/dependency><\/code><\/pre>\n
    This tells Maven not to include libX<\/code> version 1.0 from Library A<\/strong>.<\/p>\n
    4. Using mvn dependency:tree<\/code> to Investigate Dependencies<\/strong><\/h3>\n
    Maven provides the dependency:tree<\/code> command to show a hierarchical view of all dependencies, including their transitive dependencies. This is very useful for identifying version conflicts.<\/p>\n
    mvn dependency:tree<\/code><\/pre>\n
    This will display the entire dependency tree, showing which versions of libraries are being pulled in and where conflicts might exist.<\/p>\n
    Example Output:<\/h4>\n
    [INFO] com.example:project:jar:1.0\n[INFO] +- com.example:libraryA:jar:1.0:compile\n[INFO] |  \\- com.example:libX:jar:1.0:compile\n[INFO] +- com.example:libraryB:jar:1.0:compile\n[INFO] |  \\- com.example:libX:jar:2.0:compile\n[INFO] \\- com.example:libraryC:jar:1.0:compile\n[INFO]    \\- com.example:libX:jar:2.0:compile<\/code><\/pre>\n
    In this case, you can see that libX<\/code> version 1.0 is pulled in by libraryA<\/code>, and version 2.0 is pulled in by libraryB<\/code> and libraryC<\/code>. This can help you determine which dependency is causing the conflict.<\/p>\n
    5. Using exclusions<\/code> and dependencyManagement<\/code> Together<\/strong><\/h3>\n
    In some cases, you may want to both exclude conflicting versions and explicitly define the version you want. For instance:<\/p>\n
    <dependency>\n    <groupId>com.example<\/groupId>\n    <artifactId>libraryA<\/artifactId>\n    <version>1.0<\/version>\n    <exclusions>\n        <exclusion>\n            <groupId>com.example<\/groupId>\n            <artifactId>libX<\/artifactId>\n        <\/exclusion>\n    <\/exclusions>\n<\/dependency>\n\n<dependencyManagement>\n    <dependencies>\n        <!-- Enforce version of libX -->\n        <dependency>\n            <groupId>com.example<\/groupId>\n            <artifactId>libX<\/artifactId>\n            <version>2.0<\/version>\n        <\/dependency>\n    <\/dependencies>\n<\/dependencyManagement><\/code><\/pre>\n
    This ensures that you only get the version 2.0 of libX<\/code>, regardless of what versions are pulled in by other libraries.<\/p>\n
    6. Enforcing Version With dependencyVersion<\/code> Plugin<\/strong><\/h3>\n
    If you want to enforce specific versions across your project, you can use the versions-maven-plugin<\/code> to report and enforce dependency versions.<\/p>\n
    Example of Enforcing Versions:<\/h4>\n
    mvn versions:use-latest-versions<\/code><\/pre>\n
    This command will automatically update your dependencies to the latest versions according to your project's current configuration.<\/p>\n
    7. Use BOM (Bill of Materials)<\/strong><\/h3>\n
    In larger projects or when managing dependencies across multiple modules, you can use a BOM<\/strong> to centralize the versions of dependencies. BOMs can be used to ensure that all modules use the same version of a dependency.<\/p>\n
    Example:<\/h4>\n
    <dependencyManagement>\n    <dependencies>\n        <dependency>\n            <groupId>com.example<\/groupId>\n            <artifactId>libX<\/artifactId>\n            <version>2.0<\/version>\n        <\/dependency>\n    <\/dependencies>\n<\/dependencyManagement><\/code><\/pre>\n
    If you're using a third-party BOM, you can import it into your pom.xml<\/code> as follows:<\/p>\n
    <dependencyManagement>\n    <dependencies>\n        <dependency>\n            <groupId>org.springframework<\/groupId>\n            <artifactId>spring-framework-bom<\/artifactId>\n            <version>5.3.10<\/version>\n            <scope>import<\/scope>\n            <type>pom<\/type>\n        <\/dependency>\n    <\/dependencies>\n<\/dependencyManagement><\/code><\/pre>\n
    This ensures that all Spring-related dependencies are consistent across all modules of your project.<\/p>\n
    \n
    Summary<\/h3>\n
    To resolve version conflicts in Maven, you can:<\/p>\n