Re: [DISCUSS] Apache NiFi distribution has grown too large

Nice discussion on this thread. I'm also in favor of the long-term solution being publishing extension NARs to an extension registry (#3) and removing them from the NiFi convenience binary. A few thoughts that build upon what others have said: 1. Many decisions, such as the structure of the

Re: [DISCUSS] Apache NiFi distribution has grown too large

I still like the "NAR packs" idea even for the single repo approach. I think if we only provide a "light" binary and then say that everything else has to be built on your own, it creates a big barrier to entry for a lot of users. With the NAR packs approach we could provide one binary that is the

Re: how to declare dependency?

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

ReportingLineageToAtlas

Hi I am trying to set NiFi 1.5 with Atlas 0.8 in HDP 2.6, however I am getting the following error  java.lang.NoClassDefFoundError: Could not initialize class org.apache.nifi.atlas.NiFiAtlasHook Is there anything to do in addition of building NiFi with Atlas profil and setting the

[DISCUSS] MiNiFi Releases

Hey folks, With the release of NiFi 1.5 we have a current gap in the typical flow performed in taking a template with an RPG to connect from a MiNiFi instance to NiFi as discovered in MINIFI-421[1]. NiFi adjusted the relationship of input port identifiers in remote processing groups which

Re: how to declare dependency?

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

Re: [DISCUSS] Apache NiFi distribution has grown too large

Also maybe #4: Message Queue support (JMS, Kafka, etc.) On Tue, Jan 16, 2018 at 5:13 AM, Mike Thomsen wrote: > One possibility: 3 "packs." Such as: > > 1. Big Data. > 2. Search > 3. Non-BD NoSQL. > > Each pack would be an assembly of NARs that correspond to the category.

Re: [DISCUSS] Apache NiFi distribution has grown too large

One possibility: 3 "packs." Such as: 1. Big Data. 2. Search 3. Non-BD NoSQL. Each pack would be an assembly of NARs that correspond to the category. The core would have JDBC support and all of the data mutator processors. On Mon, Jan 15, 2018 at 11:54 PM, James Wing wrote: