nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Payne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NIFI-391) Need ability to deprecate components
Date Wed, 18 Mar 2015 17:28:39 GMT

    [ https://issues.apache.org/jira/browse/NIFI-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367522#comment-14367522
] 

Mark Payne commented on NIFI-391:
---------------------------------

Dan,

Matt and I discussed this a bit. The java.lang.Deprecated is cool for obvious reasons. Unfortunately,
though, it does not provide the ability to specify WHY a component was deprecated, or what
its replacement is. So we've discussed creating our own Deprecated annotation (maybe we should
use a different name?) that allows the developer to explain why it is deprecated, such as
"This Processor is replaced by this other one." It may also make sense to have a Replaced
annotation or something like that that supports this notion, while @Deprecated would simply
indicate that the Processor is going to be removed because its functionality is no longer
needed? Any other ideas on this?

It should apply to Processors, Controller Services, and Reporting Tasks. It should not apply
to properties or relationships.

> 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
>             Fix For: 0.2.0
>
>
> 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.4#6332)

Mime
View raw message