To extend this question a little bit further. This is imaginatory problem, but I feel the answer to it will help me in future.
Lets say, that I need to have dependency on nifi-record or some module providing interface. I cannot add it as compile scope dependency, since otherwise existing implementors of won't work, as they are existing in another classloader only, and noone implements interface bundled in my nar. That's clear. I have to add dependency on nar in nar module, and provided scope dependency in module with processor. Easy. Now I want to reuse another thing from different nar. Uuups, does not work, I cannot add 2 nar dependencies. What can one do with that? I assume there isn't (severe) reusability limitation, that one cannot reuse classes from more than one nar, right? Mar. 2018-01-15 22:50 GMT+01:00 Martin Mucha <[email protected]>: > Thanks guys! > > Just to sum our case up for potential future readers. We did try to define > such libraries as 'compile' scope, but (probably due to nar packaging) we > was now providing those 'dependencies' in our nar. Not what we wanted. > Example: there was missing one module, which contained only interface. > Marking it as compile fixed errors, but then we wasn't able to use > implementors of such interface, because now this interface was issued by > our nar, and obviously noone implemented that one. > > Instead, when we declared dependency on nifi-standard-services-api-nar, > provided scope worked ok, and everything else as well. > > Thanks for your help! > Martin. > > 2018-01-12 16:29 GMT+01:00 Bryan Bende <[email protected]>: > >> In addition to what Matt said, the reason nifi-record is marked as >> provided is because it is part of nifi-standard-services-api-nar, and >> if your NAR was going to do anything with a record reader/writer you >> would have a NAR dependency on nifi-standard-services-api-nar so at >> runtime that is where your NAR would get nifi-record from. At build >> time it gets it from the provided dependency in order to compile. >> >> On Fri, Jan 12, 2018 at 10:16 AM, Matt Gilman <[email protected]> >> wrote: >> > Mar, >> > >> > By using a dependency like that (without the version), it must be >> declared >> > in dependencyManagement someplace. If the jar isn't being pulled into >> the >> > resulting artifact it's likely because the dependency has a scope of >> > provided. You can override that scope to compile when you reference it. >> > >> > Matt >> > >> > On Fri, Jan 12, 2018 at 8:34 AM, Martin Mucha <[email protected]> >> wrote: >> > >> >> Hi, >> >> >> >> in nifi-standard-processors there is this dependency >> >> >> >> <dependency> >> >> <groupId>org.apache.nifi</groupId> >> >> <artifactId>nifi-record</artifactId> >> >> </dependency> >> >> >> >> if I just copy paste into our project some class from this bundle (to >> fix >> >> bugs) and add dependencies as mentioned one, it builds. However nifi >> wont >> >> start, because nifi-record related classes are not on classpath. >> >> >> >> What shall I do to get them on classpath? For nifi-standard-processors >> it's >> >> fine to have nifi-record as provided, but apparently for our project, >> >> extending the same parent, it's not. nifi-record is not provided or >> part of >> >> built nar. How to fix this? >> >> >> >> thanks, >> >> Mar. >> >> >> > >
