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
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
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
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
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.
Hi,
in nifi-standard-processors there is this dependency
org.apache.nifi
nifi-record
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
Hi,
in nifi-standard-processors there is this dependency
org.apache.nifi
nifi-record
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
