Hello, The purpose of displayName is to allow changing the name shown in the UI without breaking existing flows, meaning it still uses the original name behind the scenes in flow xml/json, but just shows a different name in the UI, so the primary purpose is for them to be different.
Since it was hard to know what the real name was, a recent release added a new column in the documentation called "API Name". Example for ConsumeKafka_2_6 processor: https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-kafka-2-6-nar/1.19.1/org.apache.nifi.processors.kafka.pubsub.ConsumeKafka_2_6/index.html Thanks, Bryan On Mon, Dec 12, 2022 at 1:21 PM Mathew Kiprop <mathewkipro...@gmail.com> wrote: > > Hello all, > > I hope this is the right thread to raise this. > I have recently been working with nipyapi[1] creating flows and found > challenge when configuring components(processors/CS) properties whose > PropertyDescriptor$displayName is different than PropertyDescriptor$name. > I had to use browser inspection tools to see how the request is submitted > by NiFi fronted, alternatively checking the name in the source code. > > Moving to 2.0, would it be good to standardize on PropertyDescriptor$name > and displayname? > > Thanks, > Mathew. > [1] https://github.com/Chaffelson/nipyapi > > On Mon, 12 Dec 2022 at 19:46, David Handermann <exceptionfact...@apache.org> > wrote: > > > Hi Isha, > > > > As the scope of the proposed release goals does not include changing the > > Site-to-Site protocol, that setup should work. Any kind of breaking > > compatibility changes will need to be documented, but the general goal is > > to make the upgrade as seamless as possible to encourage adoption. > > > > Regards, > > David Handermann > > > > On Mon, Dec 12, 2022 at 4:12 AM Isha Lamboo < > > isha.lam...@virtualsciences.nl> > > wrote: > > > > > Hi all, > > > > > > This may be too basic/self-explanatory to count as a goal at all, but > > will > > > site-to-site interoperability between NiFi 1.x and NiFi 2.x nodes will be > > > preserved? > > > > > > Regards, > > > > > > Isha > > > > > > -----Oorspronkelijk bericht----- > > > Van: David Handermann <exceptionfact...@apache.org> > > > Verzonden: zondag 11 december 2022 04:08 > > > Aan: Otto Fowler <ottobackwa...@gmail.com> > > > CC: dev@nifi.apache.org > > > Onderwerp: Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0 > > > > > > Hi Otto, > > > > > > Thanks for the reply, that is a good question. > > > > > > There is certainly a need to maintain the current version 1 branch for > > > some amount of time, but the exact amount of time will need to be > > > determined. > > > > > > Point 10 of the Proposed Release Goals includes implementing migration > > > tools, which will have to be implemented in subsequent version 1 > > releases, > > > so support for version 1 would not go away any time soon. It will become > > > more difficult to maintain libraries as time goes on, but we should also > > > identify some strategies for subsequent maintenance releases. > > > > > > I anticipate the need for future votes to sunset version 1, but that > > > should not occur until there has been significant work on version 2 and > > > associated migration tools, with documentation. > > > > > > The main purpose of the 2.0 Proposed Release Goals is to focus that > > scope, > > > and as you noted, we should give some parallel consideration to scoping > > for > > > version 1 releases. > > > > > > Regards, > > > David Handermann > > > > > > On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ottobackwa...@gmail.com> > > > wrote: > > > > > > > Sorry to be late to this, the goals seem great. The question that > > > > comes to my mind is will the current 1.x line will be maintained? > > > > > > > > That may be a parallel issue to the goals, but it is important if we > > > > are dropping support for Java versions. > > > > > > > > I would think that *some* position on that has to be decided and > > > > communicated ( if not voted on ). > > > > > > > > > > > > >
