基于Gradle v7.3.3创建统一管理Log4j版本的Java内部库及打包异常问题咨询

Hey there! Let's break down your problem and the best solutions for managing Log4j versions across all your microservices.

First, why isn't Log4j showing up in your library's JAR? That's actually expected behavior from Gradle. When you use implementation (or even api) dependencies in a Java library project, Gradle doesn't package those dependencies into your final JAR. Instead, it marks them as transitive dependencies—meaning any project that depends on your library will automatically pull in Log4j at the version you specified. This is intentional to avoid duplicate class files and dependency conflicts across your microservices.

Now, for your core goal: creating a single source of truth for Log4j versions so you don't have to update every microservice's build.gradle every time a new patch comes out. There are two great approaches for this, depending on your needs:

Option 1: Use a Gradle BOM (Bill of Materials) – Recommended for Simple Version Management #

A BOM is a lightweight way to define version constraints for a set of dependencies. It doesn't require any Java code—just a simple Gradle project that publishes version rules.

Step 1: Create the BOM Project #

Make a new Gradle project and configure its build.gradle like this:

plugins {
    id 'java-platform'
    id 'maven-publish'
}

group = 'com.mycompany.log4j'
version = '1.0.0'

// Allow the BOM to declare dependency constraints
javaPlatform {
    allowDependencies()
}

dependencies {
    constraints {
        // Enforce strict Log4j versions for all downstream projects
        implementation('org.apache.logging.log4j:log4j-api:2.17.0') {
            version { strictly '[2.17.0]' }
        }
        implementation('org.apache.logging.log4j:log4j-core:2.17.0') {
            version { strictly '[2.17.0]' }
        }
        // Add other Log4j-related dependencies here (e.g., log4j-slf4j-impl) if needed
    }
}

// Publish to your internal Maven repo (Nexus/Artifactory)
publishing {
    repositories {
        maven {
            url = uri('https://your-internal-repo-url.com/maven2')
            credentials {
                username = project.findProperty('repoUser') ?: System.getenv('REPO_USER')
                password = project.findProperty('repoPass') ?: System.getenv('REPO_PASS')
            }
        }
    }
    publications {
        mavenJava(MavenPublication) {
            from components.javaPlatform
        }
    }
}

Step 2: Use the BOM in Your Microservices #

In each microservice's build.gradle, import the BOM and declare Log4j dependencies without versions:

plugins {
    id 'java'
}

repositories {
    mavenCentral()
    maven { url 'https://your-internal-repo-url.com/maven2' }
}

dependencies {
    // Import the BOM to enforce Log4j versions
    implementation platform('com.mycompany.log4j:company-log4j-bom:1.0.0')
    
    // Declare Log4j dependencies – no version needed!
    implementation 'org.apache.logging.log4j:log4j-api'
    implementation 'org.apache.logging.log4j:log4j-core'
}

When you need to update Log4j, just change the version numbers in the BOM project, republish it with a new version (e.g., 1.0.1), and update the BOM version in your microservices.

Option 2: Create a Utility Library (If You Need Shared Logging Code) #

If you want to include shared logging utilities (like your Library class) along with version management, adjust your existing library project:

Update Your Library's build.gradle #

Use api dependencies instead of implementation if you want the Log4j APIs to be visible to microservices using your library (though implementation still works for transitive dependency resolution):

plugins {
    id 'java-library'
    id 'maven-publish'
}

group = 'com.mycompany.log4j'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    api ('org.apache.logging.log4j:log4j-api') {
        version { strictly '[2.17.0]' }
    }
    api ('org.apache.logging.log4j:log4j-core') {
        version { strictly '[2.17.0]' }
    }
}

// Publish to your internal repo (same as BOM)
publishing {
    // ... same repo configuration as above
}

Use the Library in Microservices #

Now your microservices only need one dependency to get both your utility code and the correct Log4j version:

dependencies {
    implementation 'com.mycompany.log4j:company-log4j:1.0.0'
}

Again, updating Log4j just requires changing the version in your library's build.gradle, republishing, and updating the library version in microservices.

Key Takeaway #

Your initial library's JAR not containing Log4j isn't a bug—it's Gradle's way of avoiding dependency bloat and conflicts. For version management, a BOM is the cleanest approach, while a utility library works great if you need shared logging logic.

内容的提问来源于stack exchange，提问作者Chris F