Thanks. This ties in to your answer on RecordReader etc. There's a chance I missed it but I believe those things (e.g. nifi-api is meant to be backwards compatible, other parts are not) are not documented anywhere. It'd be good to have that in my opinion. I can put it on my todo list if others agree that this would be worthwhile.
Yes, something specific last week triggered this but I can't remember what to be honest. Lars On Fri, Apr 5, 2019 at 6:35 PM Bryan Bende <bbe...@gmail.com> wrote: > 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 <lars.fran...@gmail.com> > 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 >
