Ticket #481 (closed defect: fixed)
Opened 2010-03-22T19:02:18-05:00
Last modified 2010-07-13T16:58:30-05:00
scan-deps.pl does not detect that unit tests depend upon log4j JARs
| Reported by: | melissa | Owned by: | melissa |
|---|---|---|---|
| Priority: | trivial | Milestone: |
|
| Component: | build | Severity: | minor |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
Several of the tests in the 'common' and 'bio-formats' components fail if slf4j-api-1.5.10.jar and/or log4j-12-1.5.10.jar are not in the classpath. However, scan-deps.pl does not detect that these JARs are required, and so will print a warning if the are added to the classpath, e.g.
Dependency mismatch for LOCI Common compile time classpath:
project deps =
library deps = slf4j-api testng
component.classpath = ${lib.dir}/slf4j-api-1.5.10.jar ${lib.dir}/slf4j-log4j12-1.5.10.jar ${lib.dir}/log4j-1.2.15.jar ${lib.dir}/testng-5.11-jdk15.jar
Dependency mismatch for LOCI Common runtime classpath:
project deps =
reflected projects =
library deps = slf4j-api testng
reflected libraries =
component.runtime-cp = ${lib.dir}/slf4j-api-1.5.10.jar ${lib.dir}/slf4j-log4j12-1.5.10.jar ${lib.dir}/log4j-1.2.15.jar ${lib.dir}/testng-5.11-jdk15.jar
Fixed in r6085.
First of all, slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar are not actually needed to compile the LOCI Common package—they are only used at runtime. So if they are specified in build.properties at all, they should be specified in component.runtime-cp rather than component.classpath.
Secondly, slf4j-api-1.5.10.jar does not have a proper ClassPath entry in its manifest (due to the agnosticism of its logging API), so the dependent JARs do not get loaded unless they are explicitly set on the classpath. (That said, the log4j JARs are not actually "dependent"—see the slf4j manual for details.)
As a consequence, to use loci-common.jar with log4j, it must have three log4j-related JARs in its runtime classpath, even though two of them are "dependencies of a dependency," which violates good dependency chaining practices.
To work around, I added lines to one of the LOCI Common classes noting that slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar are used via reflection, which tricks scan-deps.pl into a successful dependency matching.
However, the fact is that loci-common.jar does not specifically need slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar in its runtime classpath at all—any one slf4j binding will do. One thing I did not verify is what happens if NO such binding is present on the classpath. Will classes like loci.common.Location still load, or must there be at least slf4j-nop-1.5.11.jar on the classpath?
We should discuss our policy with respect to the slf4j logging framework, as it introduces non-trivial dependency problems at every level of our codebase.