Team For those interested I am going to take a stab at working through the codebase [1] to apply Apache Yetus [2] annotations to make it more clear and well communicated what are the public vs private aspects of the API.
We've had the 'nifi-api' module for some time now but unless you know that this was meant to be the public API for supported extension types you'd not really know that other parts of NiFi were not meant to be altered and could be changed. Therefore, we've not been able to evolve the framework as directly as we'd like at times. We had to wait until 1.0 to make changes which otherwise should have been ok to make. Also, previously 'nifi-api' had a lot of extraneous bits in it that have now been refactored out to where they belong such as core framework itself or in a 'nifi-framework-api' module. This means things in 'nifi-api' should be quite stable and public. Yetus gives us a chance to clearly articulate which parts of the API are meant for public use and which are meant for private use only and therefore are subject to change. Furthermore, even for those public elements we can more effectively articulate stability in ways that map really nicely to our versioning scheme. My intent is to be very cautious in labeling anything beyond the nifi-api as public. We can open things up as they prove to be stable or clearly need to be made available as supported points of extension but we can't really go back the other way. We of course also have to realize our 'interface' is more than these APIs we're talking about. It is the REST interface, it is configuration files, it is templates, and so on. Anyway, I hope to have the PR up for this very soon but wanted to send a special note to the dev mailing list in case there are folks particularly interested in this and who want to share their views. If you are please keep an eye out for NIFI-1373. [1] https://issues.apache.org/jira/browse/NIFI-1373 [2] https://yetus.apache.org/documentation/0.3.0/audience-annotations-apidocs/ Thanks Joe
