I may have something to test that ;) I’ll let you know, else my pr will get the ‘why are you updating the sdk version’ comment.
On March 16, 2018 at 15:57:21, Bryan Bende (bbe...@gmail.com) wrote: This should be better going forward once the 1.6.0 release is out. https://issues.apache.org/jira/browse/NIFI-4936 On Fri, Mar 16, 2018 at 3:49 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > This is also a problem for new AWS processors, say if you use a newer aws > java sdk core in a dependency but also have to depend on the nifi-aws-nar. > > > On March 2, 2018 at 13:40:21, 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 >> .
