For me the idea of 'breaking' in the extensions is no about the packages/code at all. Breaking for extensions should be about users. Where we must be extremely sure/careful about breaking is in the API. We're going to grind ourselves to a halt if we do not allow for/expect high degree of evolution in the points of extension. We designed the system this way for good reasons.
We also have this which is a helpful point of documenting principles of backward compatibility https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme I would be supportive of moving them to the proposed package without any deprecation. We took a different tack for the recent migration of Bin packing utility classes but that was a judgement call. Thanks Joe On Tue, Jan 5, 2016 at 3:57 PM, Bryan Bende <[email protected]> wrote: > Sounds good to me. #1 does address the immediate problem as you mentioned. > > Since the util package has a lot of stuff in it, my preference would be to > have a syslog package under util, or even at the same level as util. If we > did that, would moving SyslogParser and SyslogEvent to that package be > considered a breaking change? > Seems "less breaking" than moving a processor to a new package which could > break someone's flow, but still possible someone is using one of those > classes since they are public. > I can move the other stuff and leave those two alone, but just wanted to > double-check. > > -Bryan > > On Tue, Jan 5, 2016 at 4:11 PM, Joe Witt <[email protected]> wrote: > >> Bryan >> >> Great writeup on the tradeoffs. From my perspective #1 seems quite >> fine for now. I see no need to create new processors and it seems >> like the only problem to be solved right now is to make the code >> cleaner/more readable. #1 it sounds like solves that. There is >> perhaps another topic to address one day which is the grouping of >> processors within a bundle. Syslog as its own nar was probably the >> right call but this is just fine for now. When we go with a registry >> model then we will revisit these and many others anyway. >> >> Thanks >> Joe >> >> On Tue, Jan 5, 2016 at 10:22 AM, Bryan Bende <[email protected]> wrote: >> > All, >> > >> > I'm working on NIFI-1273 to add support for the RELP protocol (Reliable >> > Event Logging Protocol) to the syslog processors. In order to do this >> I'll >> > likely have to add at least one more channel reader implementation to the >> > inner classes that already exist in ListenSyslog. I'm starting to think >> > there might be a bit too much going on in there and it might be easier to >> > manage and understand if the inner classes were moved to regular classes. >> > >> > If we agree that is a good idea, then the question is where to put >> them.... >> > In hindsight it probably would have been better to have a syslog bundle, >> > instead of putting the syslog processors in the nifi-standard-processors, >> > then all of these classes could live there. The processors don't have any >> > special dependencies which is why the standard bundle initially seemed >> like >> > a good idea. >> > >> > Since we have to be careful of breaking changes, the options I see are: >> > >> > 1) Keep the syslog processors in nifi-standard-processors, and put these >> > classes under the util package where SyslogParser and SyslogEvent are. >> > Maybe create org.apache.nifi.processors.standard.util.syslog to group >> them >> > together under util. >> > >> > 2) Keep the syslog processors in nifi-standard-processors, but create a >> > nifi-syslog-utils project in nifi-commons and put all supporting code >> > there. I doubt that any other parts of NiFi would need to make use of >> this >> > artifact, but it would create a nice isolated syslog library. I think we >> > could safely move most of the inner classes there since they are private, >> > but not sure if we can move SyslogParser and SyslogEvent yet since they >> are >> > public classes in standard processors. >> > >> > 3) Create a syslog bundle with copies of the processors, do all new work >> > there, including NIFI-1273. Mark the existing processors as deprecated >> and >> > remove on 1.0. Seems unfortunate to deprecate processors one release >> after >> > releasing them, and would force anyone wanting RELP to switch to the new >> > bundle, but seems to be the only way to create a separate bundle if that >> is >> > what we wanted. >> > >> > What do others think about this? >> > >> > #1 is obviously the least intrusive and easiest, but I'm not sure it is >> the >> > best choice, especially given that we want to move to an extension >> registry >> > eventually, and would probably want to break apart some of standard >> > processors. >> > >> > #2 might be a good middle ground. Leaving the processor part for another >> > time. >> > >> > -Bryan >>
