i suspect we can eliminate the dependency management section altogether at this point in the parent pom.
On Fri, Mar 2, 2018 at 1:40 PM, Bryan Bende <bbe...@gmail.com> wrote: > 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 >> .
