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
>> .

Reply via email to