[ 
https://issues.apache.org/jira/browse/NIFI-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-1896:
------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> Extract Extension API into separate module
> ------------------------------------------
>
>                 Key: NIFI-1896
>                 URL: https://issues.apache.org/jira/browse/NIFI-1896
>             Project: Apache NiFi
>          Issue Type: Task
>          Components: Core Framework
>            Reporter: Aldrin Piri
>            Assignee: Aldrin Piri
>             Fix For: 1.0.0
>
>
> As discussed on the mailing list, the original contents of which are below:
> {quote}
> 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.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to