Russell, Assuming you have the standard project structure with a pom and then sub-modules for processors and NAR, does your root pom have a parent of nifi-nar-bundles and if so what version?
Example: <parent> <groupId>org.apache.nifi</groupId> <artifactId>nifi-nar-bundles</artifactId> <version>1.2.0-SNAPSHOT</version> </parent> It would also be helpful to see the output of mvn dependency:tree execute from your processors module. -Bryan On Mon, May 8, 2017 at 11:33 AM, Russell Bateman <r...@windofkeltia.com> wrote: > 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:tree commands 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? > >
