I'm wondering why the ExternalResourceProvider deprecation is included in this NIP. I have never used ExternalResourceProvider and only recently tried to understand its use, but it seems to be unrelated in scope to the ExtensionRegistryClient. I agree with its deprecation, but does it belong in this NIP?
-- Mike On Fri, Apr 3, 2026 at 11:52 AM Pierre Villard <[email protected]> wrote: > 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 >
