[
https://issues.apache.org/jira/browse/NIFI-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704843#comment-16704843
]
ASF GitHub Bot commented on NIFI-5859:
--------------------------------------
GitHub user markap14 opened a pull request:
https://github.com/apache/nifi-maven/pull/7
NIFI-5859: Build NAR Extension Definitions/docs at build time
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/markap14/nifi-maven NIFI-5859
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi-maven/pull/7.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #7
----
commit 7cecaa9a841af8c5729fd5b135db400318245bf3
Author: Mark Payne <markap14@...>
Date: 2018-11-14T20:09:25Z
NIFI-5859: Build NAR Extension Definitions/docs at build time
----
> Update NAR maven plugin to include information about Extensions
> ---------------------------------------------------------------
>
> Key: NIFI-5859
> URL: https://issues.apache.org/jira/browse/NIFI-5859
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Tools and Build
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
>
> In order to have the NiFi Registry host any extensions, the registry will
> need a way to know what extensions exist in a given NAR. Currently, that
> information is not available directly.
> The NAR maven plugin should be updated to provide a list of extensions and
> for each one, provide at least the following minimal information:
> * Extension Type
> * Extension Name
> * Capability Description
> * Whether or not the component is Restricted, "sub-restrictions" it has, and
> explanations of both
> * Any Tags that the component has
> * If the component is a Controller Service, any Controller Service API's
> that it provides
> Additionally, it would be ideal to provide all documentation for the
> component within the NAR. It is best, though, not to write the documentation
> in HTML as is done now but rather in XML or some sort of form that provides
> the information in a structured way without any styling. This would allow the
> documentation to be rendered consistently, even if the styling changes from 1
> version to the next.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
