A clever way to unify loggers to SLF4J in Java / build.gradle entry / 2019

This article is for people who want to use SLF4J.

• I should have unified it to SLF4J, but sometimes a mystery log appears on the console. There is no time
• Class path contains multiple SLF4J bindings. SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
• ʻERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console ... `
• I know that it can be excluded by excluding with gradle / maven, but when a new library is added, the log4j implementation is mixed and the log disappears.
• I want to remove log4j and commons-logging all at once

Update

• Spring Boot 2.0 has changed the world view so much, so I rewrote it.

Tips

About exclusion

Bulk exclusion can be done with the following syntax

configurations.all {
    exclude
}

Unification of dependent versions

[3 \ .2 . Using Spring Boot's dependency management in isolation](https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#managing-dependencies-using-in -isolation) is convenient

Even if you don't use Spring Boot, you can think of it as a Gradle Plugin and use it.

build.gradle

plugins {
	id 'org.springframework.boot' version '2.1.8.RELEASE' apply false
}

apply plugin: 'io.spring.dependency-management'

dependencyManagement {
	imports {
		mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
	}
}

with this

• Eliminates the need to write individual versions when actually using

build.gradle

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
}

I get angry when I have multiple SLF4J jars About Class path contains multiple SLF4J bindings.

It seems to be an issue of IntelliJ, but if you are using SLF4J in the dependent library and you install another version of the library with runtime, there is a problem that both Jar are included in Classpath when Debug / Run from within IntelliJ. It seems. ..

Basically, it's okay if you have dependencyManagement.

TL;DR

Pattern 1

All the projects should have various log libraries> Output with SLF4J, and the necessary modules should be included, and the implementation of various log libraries should be excluded.

build.gradle

buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath "org.springframework.boot:spring-boot-gradle-plugin:2.1.8.RELEASE"
    }
}

allprojects {
    apply plugin: "io.spring.dependency-management"

    repositories {
        mavenCentral()
    }

    dependencyManagement {
        imports {
            mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
        }
    }
}

apply plugin: 'java'

dependencies {
    // Used compile/coding time.
    implementation 'org.springframework.boot:spring-boot-starter-logging' //Actually starter-Often in web dependencies

    // Used Runtime
    runtimeOnly 'org.slf4j:log4j-over-slf4j'
    // log4j 1.Only x needs to be routed individually
    //Spring in 2017 for EOL in 2015-boot-starter-Also removed from logging
    // https://github.com/spring-projects/spring-boot/issues/11148

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

configurations.all {
    exclude group: 'log4j' // = Old only log4j impl.
    exclude group: 'org.apache.logging.log4j', module: 'log4j-slf4j-impl'// = SLF4J > Log4J 2.x. (Apache Side)
    exclude group: 'org.slf4j', module: 'slf4j-log4j12' // = SLF4J > Log4J 1.x. (SLF4J Side)
    exclude group: 'org.slf4j', module: 'slf4j-jdk14' // = SLF4J > JDK14.
    exclude group: 'commons-logging', module: 'commons-logging-api' // Replaced by jcl-over-slf4j
    exclude group: 'commons-logging', module: 'commons-logging' // Implementation is not needed.
}

Pattern 2

It is also recommended to create a log-only project that includes log settings, etc.

Write later

build.gradle

log/build.gradle