Joe Witt created NIFI-13080: ------------------------------- Summary: nifi-properties and nifi-property-utils should not be part of the public api of nifi extensions such as processors, controller services and reporting tasks Key: NIFI-13080 URL: https://issues.apache.org/jira/browse/NIFI-13080 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt
After the great refactor of NIFI-12998 a few scenarios emerged that we should resolve. The bom/parents for NiFi extensions such as nifi-extension-bundles should enforce that a pom should not have a declared dependency on nifi-properties and nifi-property-utils. nifi-property-utils has extensive usage today due to a StringUtils class. The purpose of that StringUtils class seems to be to have a very lightweight copy of things often found in commons-lang3 but when we don't want to pull in that dependency to every module. It isn't clear how valuable that is at this point and it is worth review. But either way StringUtils of nifi-property-utils does not seem like it should be a thing or should not be where it is. The handful of remaining 'nifi-extension-bundle modules that do use NiFiProperties are extensions which also don't really belong in the nifi-extension-bundle module but instead should be in a 'nifi-framework-extensions' bundle module as these are things which are more like framework extensions that the public/intentional components of processors, controller services, and reporting tasks and these framework focused extensions have different obligations/accesses such as NiFiProperties being totally fair game. But for a processor to depend on NIFi properties is a 'config/user experience smell' -- This message was sent by Atlassian Jira (v8.20.10#820010)