[
https://issues.apache.org/jira/browse/NIFI-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001253#comment-16001253
]
ASF GitHub Bot commented on NIFI-391:
-------------------------------------
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/1718
@trixpan How did you want to handle this PR? Should we get this part merged
into master and then the UI work can follow? The only reason this might be a
good idea is that we won't have to struggle to keep this PR current if the UI
portion is going to require input from multiple people. There was a lot of good
ideas in mailing list conversation [1] that should be considered and weighed
against the details currently displayed.
Thoughts?
[1]https://lists.apache.org/thread.html/2506b9e1992c2c7ba2854811744ac8b84049f5b5b580621c936af89e@%3Cdev.nifi.apache.org%3E
> Need ability to deprecate components
> ------------------------------------
>
> Key: NIFI-391
> URL: https://issues.apache.org/jira/browse/NIFI-391
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Core Framework, Core UI, Extensions
> Reporter: Mark Payne
> Assignee: Andre F de Miranda
>
> The API should allow processors to be marked as deprecated such that the UI
> then shows on the graph that the Processor is deprecated.
> Additionally, the UI should show in the Status Bar that there are deprecated
> components (processors, reporting tasks, controller services) in the flow.
> This valuable because of improvements such as NIFI-377. In this case, we have
> a community member making the Base64EncodeContent processor more generic so
> that it can encode/decode base 16,32, and 64. At this point,
> Base64EncodeContent doesn't make sense as a name, so there is a more generic
> EncodeContent processor. We don't need both, so we want to deprecated the
> Base64EncodeContent processor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
