[
https://issues.apache.org/jira/browse/NIFI-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173267#comment-17173267
]
Joe Witt commented on NIFI-7718:
--------------------------------
I like the general idea. I am not in favor of subprojects per language/client.
Rather we could consider a single subproject for many languages. One source
release with potentially zero or more convenience binaries.
Alternatively, we need to discuss merging back into fewer source repositories
generally. The overhead/timing of various releases like NiFi and NiFI Registry
and MiNiFI Java has proven too burdensome. We're collapsing minifi-java back
into NiFi. We need to consider what options we have broadly
> create NiFi sub projects to host NiFi REST client in different languages
> ------------------------------------------------------------------------
>
> Key: NIFI-7718
> URL: https://issues.apache.org/jira/browse/NIFI-7718
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Tools and Build
> Reporter: Simon Weng
> Priority: Minor
>
> We're seeing the need of NiFI REST clients in different languages, such as
> Python, Go, etc, so that software can be created to control and manage NiFi
> cluster and flows.
> Since the RESTful API is documented in OpenAPI spec v2, a client SDK can be
> generated via
> [openapi-generator|https://github.com/OpenAPITools/openapi-generator]
> Individual effort is seen from the community, such as:
> * [https://github.com/erdrix/nigoapi]
> * [https://github.com/simingweng/nifi-go-client]
> * [https://github.com/Chaffelson/nipyapi]
> It would be beneficial to the community to consolidate the effort and
> centrally maintain the Client SDK effort for everybody to use.
> Just like \{{minifi}} being a sub project of NiFi, we can create sub project
> for each language binding, such as:
> * apache/nifi-client-go
> * apache/nifi-client-python
> A \{{repo-per-language}} approach is favored for various reasons, take
> [https://github.com/kubernetes-client] as sample:
> * each language has its idiomatic way to publish and share
> * easier for contributor to maintain and release
> * each language may require different custom templates, almost certainly
> different code generation configurations
> * some language has tighter couple with repo and their dependencies
> management, like Go
> This means higher initial logistic effort to set those sub projects up, but
> it can be done gradually.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
