Okapi XLIFF lib 1.39.0 breaks logging configuration

[Vedran Pavić]

The 1.39.0 release of net.sf.okapi.lib:okapi-lib-xliff2 pulls in net.sf.okapi.logbind:build-logback transitively as can be seen in the dependency tree listed by Gradle:

+--- net.sf.okapi.lib:okapi-lib-xliff2:1.39.0
|    +--- org.slf4j:slf4j-api:1.7.29 -> 1.7.30
|    \--- net.sf.okapi.logbind:build-logback:1.39.0
|         +--- ch.qos.logback:logback-core:1.2.3
|         +--- ch.qos.logback:logback-classic:1.2.3 (*)
|         \--- com.mihnita:color-loggers:1.0.5
|              +--- log4j:log4j:1.2.17
|              +--- org.slf4j:slf4j-api:1.7.21 -> 1.7.30
|              +--- ch.qos.logback:logback-core:1.1.7 -> 1.2.3
|              +--- ch.qos.logback:logback-classic:1.1.7 -> 1.2.3 (*)
|              \--- org.fusesource.jansi:jansi:1.13

The issue with net.sf.okapi.logbind:build-logback artifact is that it contains a logback.xml file which breaks logging configuration for users that use Logback as logging framework. The presence of logback.xml aside, it’s also very invasive that a library pulls in a logging framework (such as Logback) as a compile runtime time dependency since that can have significant impact on users' own logging configuration.

Please limit the transitive dependencies so that the library is more considerate to users' own logging preferences.

[Chase Tingley]

cc @Mihai Nita

[Mihai Nita]

Darn I’ll take a look later today.

[Mihai Nita]

I’ve spent some time on this, and I am puzzled.

How can I see this gradle report?

The lib-xliff2/pom.xml does not list logbind as a dependency.
The parent pom.xml (in libraries) does not do that either.
The one above does, but as runtime not compile

The official distribution (in maven) does not have that dependency either, see the pom at https://repo1.maven.org/maven2/net/sf/okapi/lib/okapi-lib-xliff2/1.39.0/
The applications use the jdk logging, not the logback (which is only build-time).

So we really try to be considerate of the user’s logging preferences.
But we need a build time (unit-test) logger.
I don’t see any indication that the build time logger “leaks” to the Okapi users, no matter if they consume Okapi by downloading the libs, the apps, or through maven.

Using the mvn dependency:tree I get

[INFO] -----------------< net.sf.okapi.lib:okapi-lib-xliff2 >------------------
[INFO] Building Okapi Library for XLIFF 2 1.40.0-SNAPSHOT              [52/179]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ okapi-lib-xliff2 ---
[INFO] net.sf.okapi.lib:okapi-lib-xliff2:jar:1.40.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.13:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- com.tngtech.java:junit-dataprovider:jar:1.13.1:test
[INFO] +- org.slf4j:slf4j-api:jar:1.7.30:compile
[INFO] \- net.sf.okapi.logbind:build-logback:jar:1.40.0-SNAPSHOT:runtime
[INFO]    +- ch.qos.logback:logback-core:jar:1.2.3:runtime
[INFO]    +- ch.qos.logback:logback-classic:jar:1.2.3:runtime
[INFO]    \- com.mihnita:color-logger-logback:jar:1.0.7:runtime
[INFO]       \- org.fusesource.jansi:jansi:jar:1.18:runtime

Note the runtime next to everything logging related, which I don’t see in the graddle report.

“pulls in a logging framework (such as Logback) as a compile time dependency”
I can’t see this, in our maven build this is a runtime dependency.
Since we don’t use gradle to build Okapi, this makes me think that it’s a problem with the custom gradle build?

---

Even ignoring gradle, I think that we agree that we need a build time logger.
Right now you can build with any logger supported by slf4j. In fact we did build with SimpleLogger for a while.

All it takes:

• add a okapi\deployment\logbind-foo
• list it as runtime dependency in okapi\pom.xml

But I have no idea how would one replace the build time logger without any changes.
And without adding any extra burdens for those who don’t care what the build time logger is?

Thank you,
Mihai

[Vedran Pavić]

Thanks for the feedback Mihai.

“pulls in a logging framework (such as Logback) as a compile time dependency”
I can’t see this, in our maven build this is a runtime dependency.

I should correct myself here - yes, the problematic dependency is of runtime scope but that doesn’t change the core problem as it’s resolved transitively.

It’s OK and expected for a library to depend on some logging API, but concrete logging implementations shouldn’t be pulled in transitively and especially not together with logging configurations being pulled to the classpath as well. It’s understandable your build and tests need some logging, but why can’t you use test scope for implementation specific dependencies?

A minimal sample to reproduce this would be a build.gradle like this:

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'net.sf.okapi.lib:okapi-lib-xliff2:1.39.0'
}

Running gradle dependencies --configuration runtimeClasspath against this yields:

$ gradle dependencies --configuration runtimeClasspath

> Task :dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

runtimeClasspath - Runtime classpath of source set 'main'.
\--- net.sf.okapi.lib:okapi-lib-xliff2:1.39.0
     +--- org.slf4j:slf4j-api:1.7.29
     \--- net.sf.okapi.logbind:build-logback:1.39.0
          +--- ch.qos.logback:logback-core:1.2.3
          +--- ch.qos.logback:logback-classic:1.2.3
          |    +--- ch.qos.logback:logback-core:1.2.3
          |    \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.29
          \--- com.mihnita:color-loggers:1.0.5
               +--- log4j:log4j:1.2.17
               +--- org.slf4j:slf4j-api:1.7.21 -> 1.7.29
               +--- ch.qos.logback:logback-core:1.1.7 -> 1.2.3
               +--- ch.qos.logback:logback-classic:1.1.7 -> 1.2.3 (*)
               \--- org.fusesource.jansi:jansi:1.13

(*) - dependencies omitted (listed previously)

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 551ms
1 actionable task: 1 executed

‌

[Mihai Nita]

Thank you Vedran, I was able to reproduce it.

It looks like it happens for everything, including core. And we’ve been leaking this “since forever”
For example using implementation 'net.sf.okapi:okapi-core:0.35' instead of xliff2 shows the dependency on slf4j-simple

‌

[Mihai Nita]

I think I have a fix.

See okapi-core before commit 3b0b915a:

runtimeClasspath - Runtime classpath of source set 'main'.
\--- net.sf.okapi:okapi-core:1.40.0-SNAPSHOT
     +--- com.ibm.icu:icu4j:66.1
     +--- org.slf4j:slf4j-api:1.7.30
     \--- net.sf.okapi.logbind:build-logback:1.40.0-SNAPSHOT
          +--- ch.qos.logback:logback-core:1.2.3
          +--- ch.qos.logback:logback-classic:1.2.3
          |    +--- ch.qos.logback:logback-core:1.2.3
          |    \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30
          \--- com.mihnita:color-logger-logback:1.0.7
               +--- org.slf4j:slf4j-api:1.7.30
               +--- org.fusesource.jansi:jansi:1.18
               +--- ch.qos.logback:logback-core:1.2.3
               \--- ch.qos.logback:logback-classic:1.2.3 (*)

After commit:

runtimeClasspath - Runtime classpath of source set 'main'.
\--- net.sf.okapi:okapi-core:1.40.0-SNAPSHOT
     +--- com.ibm.icu:icu4j:66.1
     \--- org.slf4j:slf4j-api:1.7.30

The build.gradle used to test it:

plugins {
    id 'java'
}

repositories {
    mavenCentral()
    maven {
        url "https://oss.sonatype.org/content/repositories/snapshots"
    }
}

dependencies {
    implementation 'net.sf.okapi:okapi-core:1.40.0-SNAPSHOT'
}

It does not show in any configuration, not even test (gradle check dependencies)

[Chase Tingley]

Oh funky. I think this may be the source of the a minor but annoying issue I’ve had for a very long time involving logging in longhorn.

[Vedran Pavić]

Thanks for the follow up Mihai - I’ve taken a look at 1.40.0-SNAPSHOT and the resolved dependency tree looks good now.

[Mihai Nita]

One question…

Anything else that “bothers” you with Okapi?

I don’t think we have much feedback from anyone consuming Okapi through maven.
We thought it is a good idea and published it there. But we didn’t hear much from people using it that way.

Some of the issues are probably just because we don’t know, not that we don’t care :-)

Thank you,
Mihai

‌

[Vedran Pavić]

My colleague who’s working more closely with Okapi lib on our XLIFF related functionalities is watching this issue as well, I’ll encourage him to provide feedback on the lib if and when there’s opportunity to do so.

In any case, thanks again Mihai.

[Chase Tingley]

Yes, please do provide feedback, file bugs, submit patches, etc