I think it really comes down to a case by case basis. Generally code that is in a processor, or in a specific NAR, is not usually meant to be shared or extended from, so the best practice would be to move code like that into utility modules in nifi-nar-bundles/nifi-extension-utils so that it can be shared across many processors.
Did you have any specific changes to processors that you were thinking of? On Fri, Apr 5, 2019 at 11:33 AM Lars Francke <[email protected]> wrote: > > Hi, > > looking at Processors I often see things (e.g. internal state) are > protected, public or package private that really shouldn't/needn't be. A > few years ago I tried to change one of those and was told that others might > rely upon and I can't change it for backwards compatibility reasons. > > I've now stumbled across this again and am wondering: Is there an official > policy somewhere? I looked at the Developer section of the wiki but > couldn't find anything obvious. > > If those things really can't be changed it'd mean that only in NiFi 2.x > changes like this can come in. > > I guess this ties into the Extension Registry and separate versions of > processors & NiFi etc. > > Cheers, > Lars
