Okapi XLIFF lib 1.39.0 breaks logging configuration
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.
Comments (14)
-
-
- changed version to 1.39.0
-
Darn I’ll take a look later today.
-
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 listlogbind
as a dependency.
The parentpom.xml
(inlibraries
) does not do that either.
The one above does, but asruntime
notcompile
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 aruntime
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 inokapi\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 - add a
-
reporter 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 aruntime
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
-
reporter - edited description
-
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 usingimplementation 'net.sf.okapi:okapi-core:0.35'
instead of xliff2 shows the dependency onslf4j-simple
-
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
) -
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.
-
reporter Thanks for the follow up Mihai - I’ve taken a look at
1.40.0-SNAPSHOT
and the resolved dependency tree looks good now. -
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
-
reporter 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.
-
Yes, please do provide feedback, file bugs, submit patches, etc
-
- changed status to resolved
- Log in to comment
cc @Mihai Nita