Hi all, This definitely didn't get the love I was expecting :) Thanks Kevin for your reply to this thread.
In order to, maybe, help a bit with this discussion, I submitted a draft PR [1] with what would be the API changes for this new feature. I guess I'll need to start a new vote thread in the future as I think this feature would greatly benefit the community when using/deploying custom NARs. It would also help the project as it would be easier to no longer ship a lot of NARs but only focus on the most important ones in the convenience binary and provide documentation on how to configure an extension registry client to automatically get all of the NARs not included by default. [1] https://github.com/apache/nifi-api/pull/83 Thanks, Pierre Le jeu. 19 mars 2026 à 22:44, Kevin Doran <[email protected]> a écrit : > > Hey Pierre, > > Thanks for the write up. I am generally an advocate for more modular > nifi deployments, and this seems like a good approach. > > +1from me for a properties-configured extension registry client. > > Cheers, > Kevin > > On Thu, Mar 19, 2026 at 7:11 AM Pierre Villard > <[email protected]> wrote: > > > > Team, > > > > I'd like to start a formal vote process around NIP-4 [1] which aims to > > introduce the concept of Extension Registry Clients that would also > > deprecate the existing concept of ExternalResourceProvider for future > > removal. > > > > The initial proposal was about introducing a completely new extension point > > similar to the existing Flow Registry Clients but following discussion on > > the NIP, we would go with a multi-steps approach where the first step would > > be a nifi.properties level configuration of the extensions registry > > clients. We would then evaluate if it is worth doing the work to add those > > as true 1st class components in the NiFi UI - I have been running a POC for > > both scenarios for quite some time now but doing so has the advantage of > > making it easier to introduce breaking changes if needed. > > > > This change is also related to some additional work around the ability to > > sign NARs [2] and the extension registry clients would support the ability > > to only look for NARs that are signed by trusted entities. > > > > Finally, as we get closer to having the first release of NiFi with the new > > concept of Connectors, the Extension Registry Clients would also be a nice > > addition to externally retrieve connectors that are also packaged as NAR > > files. > > > > Given that this is not a minor change, this vote is not following the > > lazy-consensus approach and I'll leave this open for 3 days. > > > > The actual PR/code-change will still go through our normal RTC process. > > > > [1] https://issues.apache.org/jira/browse/NIP-4 > > [2] https://issues.apache.org/jira/browse/NIFI-15675 > > > > Thanks, > > Pierre
