Doh. Definitely sounds like a bug in the assembly and a perfect time to resolve it since we should be starting release candidate procedures in a couple days. Please do file a JIRA for that with a fix of 050. I am happy to fix bow that you did the hard part :) On Jan 30, 2016 5:37 PM, "James Wing" <[email protected]> wrote:
> Is anyone successfully using NiFi RPMs? I am having trouble building RPMs > that result in a working NiFi installation on a clean system. I'm not sure > if I'm just doing it wrong, or if I should create a ticket and try to fix > it. > > After building an RPM (mvn clean install -Prpm) and installing it (Amazon > Linux, Java 1.7.0_91), I ran into the following error attempting to start > NiFi : > > # ./nifi.sh start > > Java home: /usr/lib/jvm/java > NiFi home: /opt/nifi/nifi-0.4.1 > > Bootstrap Config File: /opt/nifi/nifi-0.4.1/conf/bootstrap.conf > > Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/Logger > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2625) > at java.lang.Class.getMethod0(Class.java:2866) > at java.lang.Class.getMethod(Class.java:1676) > at > sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494) > at > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486) > Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:425) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > ... 6 more > > But the .tar.gz assembly file from the same build works just fine. > Comparing listings of the two file sets, it appears that the .tar.gz > assembly has complete set of jar files in lib/bootstrap: > > * activation-1.1.jar > * antlr-runtime-3.5.2.jar > * commons-lang3-3.4.jar > * logback-classic-1.1.3.jar > * logback-core-1.1.3.jar > * mail-1.4.7.jar > * nifi-api-0.4.1.jar > * nifi-bootstrap-0.4.1.jar > * nifi-expression-language-0.4.1.jar > * nifi-processor-utils-0.4.1.jar > * nifi-security-utils-0.4.1.jar > * nifi-utils-0.4.1.jar > * slf4j-api-1.7.12.jar > > while the RPM install's lib/bootstrap has only one of these: > > * nifi-bootstrap-0.4.1.jar > > So I tried to troubleshoot why this is. It looks like the nifi-assembly > POM is set up to use the same defined set of dependencies for both the > maven-assembly-plugin and rpm-maven-plugin plugins. The lib folder plan > for both plugins is something like: > > lib - all dependencies except: > * nifi-bootstrap > > lib/bootstrap - include only: > * nifi-bootstrap > > The problem appears to be a difference between how the two plugins handle > transitive dependencies. The maven-assembly-plugin has configuration > options allowing us to specify that the exclusions apply to the named > plugins AND their transitive dependencies. The rpm-maven-plugin does not > have a transitive configuration option, and does not appear to do the same > thing by default. In fact, the RPM is built with nifi-bootstrap-0.4.1.jar > in the lib/bootstrap folder, but all of its transitive dependencies (such > as slf4j from the error) are in the lib folder. I believe the RPM installs > LICENSE and NOTICE in the docs folder for the same reason. > > But that would suggest that NiFi RPMs are not working for anyone else? >
