All, I would like to propose a refactoring of the nifi-api for our master/1.0 branch. In summary, a lightweight and concise view of this module allows for reduced footprint of the NIFI API for components and minimizes the creep of those items that authoring components do not need to use.
In a broader context there is a core set of interfaces that users will interface with in their generation of new extensions for NiFi. Summarily, these components have comprised Processors, Controller Services, Reporting Tasks, & Prioritizers (the last of which is currently under discussion to potentially be removed from this forward facing status). What I would like to suggest is the refactoring of the nifi-api module to be broken down into to two components: the nifi-api and the nifi-framework-api. nifi-api will encompass all things developers would need to provide extensions tailored toward interacting with dataflow. nifi-framework-api would address the more internal items that are also extensible, but not something that is typically implemented and would consist of the remainder of those items not in nifi-api. This enables a core set of APIs that extensions can implement with a broader perspective of providing API compatibility between both NiFi and MiNiFi. This enables some nice reuse of work with the goal ultimately amounting to, write for NiFi, run on MiNiFi and the reverse. Logistically, for NiFi extension writers, at first glance, not much would change with their efforts. The core dependency would remain the same, but would be curtailed in its scope to only what is required. Framework components of course, would need to be updated to include a dependency on nifi-framework-api. Given that the new structure would not yet be released, and to allow MiNiFi to continue on its development path, a Git submodule or subtree would be introduced into MiNiFi and supporting documentation on how to make use of this for those not familiar.
