My nightmare today is a whole test suite of JUnit cases that error out
with this and it only happens from JUnit tests, never from production code:
I have put this in my top-level /pom.xml/
<slf4j.version>[1.7.25]</slf4j.version>
but that doesn't force-feed the version to NiFi and other dependencies
that have hard-linked some different version of slf4j? I've tried to
discover some "common" version of slf4j, but when I wipe it from
/~/.m2/repository/org/apache/slf4j/, then rebuild, of course I'm left
still with multiple versions forced upon me:
~/.m2/repository/org/slf4j $ tree
.
├── jcl-over-slf4j
│ ├── 1.5.6
│ ├── 1.7.21
│ └── 1.7.25
├── jul-to-slf4j
│ └── 1.7.25
├── log4j-over-slf4j
│ └── 1.7.25
├── slf4j-api
│ ├── 1.5.6
│ ├── 1.6.6
│ ├── 1.7.10
│ ├── 1.7.19
│ ├── 1.7.21
│ └── 1.7.25
├── slf4j-jdk14
│ └── 1.5.6
├── slf4j-parent
│ ├── 1.5.6
│ ├── 1.6.6
│ ├── 1.7.10
│ ├── 1.7.19
│ ├── 1.7.21
│ └── 1.7.25
└── slf4j-simple
└── 1.7.25
I've tried mvn dependency:treecommands unsuccessfully to figure out
which among my dependencies is the culprit. My next lame attempt will be
to create a fake /slf4j/ JAR with the missing method(s), maybe using
some reflection, etc., but I don't really want to walk that thorny path.
I'm perplexed and don't know how to solve this. I've been just
@Ignore-ing all these tests for some time now, but I really need them
functional. I see a lot of folk out there in Googleland with this same
question about /slf4j/, not always satisfactorily resolve. It's hard to
believe that others don't have this problem. Incidentally, we don't
directly reference /slf4j/ in our code.
Any thoughts would be helpful. Surely someone brighter than I has
encountered and solve this problem?
