NIFI-13651 moved framework extension modules to new framework extensions module

[joewitt]

Summary

NIFI-13651

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 21

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[joewitt]

Key points:

1. nothing in 'nifi-extensions' has access/reference to NiFiProperties class anymore.
2. moved remaining extensions that are really extensions to core nifi framework and not meant as generally user extensible points to nifi-framework-extensions. These currently do reference NiFiProperties in most cases. This should be refactored out in a later JIRA
3. Removed defunct reference to NiFiProperties in an hdfs events test.

nifi-property-utils and nifi-properties should fine their way out of the root lib directory. They should at most be in the nifi framework nar and the framework extensions should likely have the framework nar as their parent to be bound at that level. But more work is needed to understand the relationship of the bootstrap folder and the properties to the framework.

[exceptionfactory]

Thanks for putting together these changes @joewitt, placing framework-level extensions in a separate category provides a very helpful distinction. The general approach looks good, I plan to take a closer look, but this appears to cover the applicable modules on initial review.

[exceptionfactory]

@joewitt Reviewing other modules in nifi-extensions-bundles, the nifi-py4j-bundle is one other candidate for moving to the nifi-framework-extensions because it supports the Python Processor integration at the framework level.

[bbende]

@joewitt @exceptionfactory Thoughts on moving nifi-framework-kubernetes-bundle under nifi-framework-extensions ? It is currently nested under nifi-framework-bundle/nifi-framework.

[exceptionfactory]

@bbende That's a good point, I agree the nifi-framework-kubernetes-bundle fits under nifi-framework-extensions as well.

[joewitt]

rgr. will grab nifi-py4j-bundle and nifi-framework-kubernetes-bundle to move there as well

[joewitt]

breaking apart the 'nifi-py4j-bundle' as a few modules go together in a framework sense. And a few modules go together as examples/tests/impls as an extension. The nifi-py4j-bridge component actually combines core framework elements and ties to extension concepts such as 'records' and such. Until we promote 'records' as part of the official/formal API this seems like the right place for these few. Will have that in the next commit but the next commit will squash and rebase to latest main as well

[joewitt]

ok i think i addressed each of the suggestions. Full clean build and all the trimmings works as expected.

[exceptionfactory]

Thanks for making the adjustments @joewitt, this is a helpful restructuring of framework-specific extension modules. +1 merging