Team, A recent shift in ASF policy toward the JSON.org license [1] as discussed here [2] means we must eliminate any usage of the JSON.org for any future releases.
The offending library which we have transitive dependency on in several places as of this writing is here [3] and the JIRA which outlines the challenge is here [4]. For the 1.x line I propose to make the following specific changes to allow us to move forward and I highlight them because they will cause some downstream user impact which we'll have to manage but appear unavoidable at this point. 1) nifi-social-media-nar / GetTwitter processor This processor utilizes the Twitter4J library which depends on the now category X code. I plan to remove the nar and ensure we do not deploy/release the nar by default. One could optionally build that component and include it if they wish to do so. Users would need to build that component/nar and include it in their build if they want it. 2) nifi-flume-nar / twitter source The flume nar bundles the twitter source which also uses twitter4j. I plan to simply remove this dependency. 3) nifi-hive-nar / Hive processors The hive processors depend on hive-common which uses this library. I plan to remove nifi-hive-nar and ensure we do not deploy/release the nar by default. The code will still be available should someone want to optionally build and include it themselves. 4) nifi-standard-nar / ValidateJSON processor This is new in 1.x line. I plan to revert this commit and reopen this JIRA for the dependency usage to get resolved. For processors/components that will not be made available by default please note that the previous 1.x release provided a feature which means flows depending on no longer available components will still come up and will allow the user to alter them. In the 0.x line the flow will not come up and the user will need to edit their flow manually to remove the offending dependency or provide it on the classpath. The release notes/highlights will be updated to very clearly reflect this situation and provide guidance to users wishing to leverage these resources. A similar path will need to be followed for the 0.x line for any future releases and I will create JIRAs to address them. For those interested in this topic please take a moment to review the state of the situation and if you see more optimal tradeoffs we can make to limit downstream consumption impact please do advise. Thanks Joe [1] http://www.json.org/license.html [2] https://lists.apache.org/thread.html/9627a9278d263378a2045d4bffccb6e83b9f01bb783c6dd6fa325faf@%3Clegal-discuss.apache.org%3E [3] https://github.com/stleary/JSON-java [4] https://issues.apache.org/jira/browse/NIFI-2991
