Doug, I think the only solution is what you proposed about fixing the nifi-gcp-bundle...
Basically, if a NAR needs a different version of a dependency that is already declared in the root pom's dependencyManagement, then the bundle's pom needs it own dependencyManagement to force it back to the specific version for the bundle. Ultimately it would be nice to re-evaluate our use of dependencyManagement in the root pom, because I don't think we should be forcing the version of so many things. Guava is a perfect example where we shouldn't be forcing all NARs to use a specific version of Guava, that defeats the whole purpose of NARs. There are other cases though where it does make sense because there is code in nifi/nifi-commons that we would likely want to keep in sync with the NARs that use the code. -Bryan On Fri, Mar 2, 2018 at 1:27 PM, Douglas Willcocks <douglas.willco...@artefact.com> wrote: > Hi all, > > I'm encountering a JAR version dependency issue when developing a custom > Processor that uses the GCPCredentialsService in Nifi 1.5.0. > > 1) The nifi-gcp-bundle distributed with Nifi 1.5.0 (which contains > GCPCredentialsService) is packaged with dependencies on: > > - com.google.cloud:google-cloud:0.8.0 > - com.google.auth:google-auth-library-oauth2-http:0.6.0 > > Which both transitively depend on com.google.guava:guava:19.0, except the > root-level pom.xml for Nifi (here > <https://github.com/apache/nifi/blob/master/pom.xml>) explicitly pins the > guava version to 18.0. > > 2) The custom Processor I am building also depends on > com.google.cloud:google-cloud:0.8.0, but actually uses methods from this > library that depend on features added in com.google.guava:guava:19.0. > > 3) In order to make the GCPCredentialsService available inside my Processor > NAR, I have added the nifi-gcp-services-api-nar as a parent. > > 4) The implementation of NarClassLoader always starts the search for > classes in the parent, which means that when my processor looks for > com.google.guava class definitions, the com.google.guava:guava:18.0 JAR > packaged with the nifi-gcp-services-api-nar is always found first, > resulting in a java.lang.NoSuchMethodError exception in my Processor's > execution. > > I'm not sure what the best solution is – I guess I could create my own > version of the nifi-gcp-bundle that has the correct pom.xml file to force > the use of guava:19.0, but that seems a bit overkill for a change that is > essentially 5 lines of XML in a POM file. > > Any suggestions or thoughts? > > Thanks! > Douglas > -- > > Douglas Willcocks > VP France, Data Science & Engineering > > 19 Rue Richer, 75009 Paris, France > M: +33 6 80 37 60 72 > E: douglas.willco...@artefact.com > > W: http://www.artefact.com/ > > -- > This email and any attachments contains privileged and confidential > information intended only for the use of the addressee(s). If you are not > an intended recipient of this email, you are hereby notified that any > dissemination, copying or use of information is strictly prohibited. If you > received this email in error or without authorization, please delete the > email from your system and notify us immediately by sending us an email. If > you need any further assistance, please send a message to he...@artefact.com > .
