Anything that is intended to be re-used across NARs should be packaged into a utility module that each NAR could include.
For example, all of the modules under nifi-extensions-utils [1] contain re-usable code that NARs can share. This case is different because it is not a service API, it just resuable code that will be included any given NAR using a standard compile dependency. [1] https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-extension-utils On Tue, Jan 16, 2018 at 6:50 AM, Martin Mucha <[email protected]> wrote: > 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. >>> >> >>> >> >>
