[jira] [Commented] (NIFI-7718) create NiFi sub projects to host NiFi REST client in different languages

["Joe Witt (Jira)" <ji...@apache.org>]

    [ 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)