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)
