Dependency on slf4j-simple conflicts with Logback on running tests with Gradle

[mpscheidt]

Given a simple Spring Boot project created with https://start.spring.io/, running tests with gradlew test works fine:

plugins {
    id 'org.springframework.boot' version '2.6.1'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    mavenCentral()
}

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

test {
    useJUnitPlatform()
}

But adding the dependency on spring-rest2ts-generator

implementation group: 'com.blue-veery', name: 'spring-rest2ts-generator', version: '1.3.0'

breaks the test run, complaining about duplicate implementations of slf4j implementation on the classpath:

1. Logback (brought in by Spring Boot Starter) and
2. slf4j-simple (dependency of spring-rest2ts-generator)

This is the error produced by gradlew test: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath. Either remove Logback or the competing implementation (class org.slf4j.impl.SimpleLoggerFactory loaded from file:/D:/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-simple/1.7.32/321ffafb5123a91a71737dbff38ebe273e771e5b/slf4j-simple-1.7.32.jar). If you are using WebLogic you will need to add 'org.slf4j' to prefer-application-packages in WEB-INF/weblogic.xml: org.slf4j.impl.SimpleLoggerFactory

Suggestion: Remove spring-rest2ts-generator's dependency on slf4j-simple. The choice for a particular logging implemenetation should be decided by the project in which spring-rest2ts-generator is being used.

Btw, the workaround to get going with Spring Boot is to exclude the dependency:

implementation group: 'com.blue-veery', name: 'spring-rest2ts-generator', version: '1.3.0', {
   exclude group: 'org.slf4j', module: 'slf4j-simple' 
}

[tomasz-wozniak75]

Hi Markus Thanks for pointing this out. I agree that we should depend only on the interfaces, we will fix that in the next major release as it could be a braking change for existing users . Meanwhile I also recommend workaround which You suggested to exclude slf4j-simple Thanks