Re: [DISCUSS] Component deprecation annotation
I agree on treating these as we do restricted ones. I will work on some recommendations for a unique icon that the chooser dialog can display as well as how to best carry that over onto the canvas component. It would also be nice to suggest the alternative in the UI, for example when the user hovers the deprecated icon in the Add Processor dialog, specifically call out the alternative(s) by name. Rob On Apr 30, 2017 10:05 PM, "Andre" wrote: All, Thank you for the feedback. I will extend the PR so that the required endpoints are in place but will leave the effective UI design to our UX experts. Hopefully I should be able to use the @Restricted as a basis for this work. Otherwise I will shout for some guidance. Cheers On Mon, May 1, 2017 at 11:23 AM, Joe Witt wrote: > Agreed on both the icon being preferable as the vehicle to show this > for processors on the graph instead of color and also in emphasizing > this during processor selection. > > Thanks > > On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess wrote: > > Visual indication on existing processors is a good thing, but IMO we'll > definitely need indication on the processor selection dialog, so the user > will know that we suggest they choose an alternative. > > > > Regards, > > Matt > > > >> On Apr 30, 2017, at 7:12 PM, Jeff wrote: > >> > >> I think an icon on the processor would be best to denote an upcoming > >> deprecation. That leaves all colors available to the flow design, since > >> any color may have specific meaning to any current flow out there. > >> > >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros > wrote: > >>> > >>> In same train of though maybe make it default to some color other than > >>> white, instinct says red but that might be used to represent an > important > >>> processor. So suggest maybe default beige? > >>> > >>> > >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto < > alopresto.apa...@gmail.com> > >>> wrote: > >>> > I'd leave the graphics work/decisions to someone like Rob Moran, but I > >>> see > it as similar to the restricted components -- an icon on the > processors > >>> on > the canvas and the dialog to add components, with additional > explanation > (and maybe a target release for full deprecation) in the help notes. > > Andy LoPresto > alopre...@apache.org > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Apr 29, 2017, at 05:16, Andre wrote: > > > > dev, > > > > In light of the some recent deprecations (ListenLumberjack) and some > > potential deprecation (PutJMS/GetJMS) I started some progress on how > to > > document the depreciation of NiFi components using annotations. > > > > In the absence of any better name I called the annotation > > @DeprecationWarning (so not overlap with Java's @Deprecated) > > > > The suggested modifications are part of PR#1718 and I am keen to hear > your > > thoughts. > > > > While the documentation can be displayed as part of the usage, > however > >>> I > > would imagine the frequency a user browses to the usage pages will > >>> reduce > > as her/him becomes familiar with the components. > > > > In light of this it may be a good idea to use the web UI to > highlight > >>> a > > processor has been deprecated. > > > > Would anyone suggest a way of doing so without disrupting the user > > experience? > > > > Cheers > > >>> >
Re: [DISCUSS] Component deprecation annotation
It would be really nice if this could be part of a summary or bulletin list that an Admin/Ops could check frequently to find out if any of the tenants on the NiFi service are using deprecated processors//controllers. On Mon, May 1, 2017 at 8:24 AM, Rob Moran wrote: > I agree on treating these as we do restricted ones. I will work on some > recommendations for a unique icon that the chooser dialog can display as > well as how to best carry that over onto the canvas component. > > It would also be nice to suggest the alternative in the UI, for example > when the user hovers the deprecated icon in the Add Processor dialog, > specifically call out the alternative(s) by name. > > Rob > > On Apr 30, 2017 10:05 PM, "Andre" wrote: > > All, > > Thank you for the feedback. > > I will extend the PR so that the required endpoints are in place but will > leave the effective UI design to our UX experts. > > Hopefully I should be able to use the @Restricted as a basis for this work. > Otherwise I will shout for some guidance. > > Cheers > > > On Mon, May 1, 2017 at 11:23 AM, Joe Witt wrote: > > > Agreed on both the icon being preferable as the vehicle to show this > > for processors on the graph instead of color and also in emphasizing > > this during processor selection. > > > > Thanks > > > > On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess > wrote: > > > Visual indication on existing processors is a good thing, but IMO we'll > > definitely need indication on the processor selection dialog, so the user > > will know that we suggest they choose an alternative. > > > > > > Regards, > > > Matt > > > > > >> On Apr 30, 2017, at 7:12 PM, Jeff wrote: > > >> > > >> I think an icon on the processor would be best to denote an upcoming > > >> deprecation. That leaves all colors available to the flow design, > since > > >> any color may have specific meaning to any current flow out there. > > >> > > >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros > > wrote: > > >>> > > >>> In same train of though maybe make it default to some color other > than > > >>> white, instinct says red but that might be used to represent an > > important > > >>> processor. So suggest maybe default beige? > > >>> > > >>> > > >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto < > > alopresto.apa...@gmail.com> > > >>> wrote: > > >>> > > I'd leave the graphics work/decisions to someone like Rob Moran, but > I > > >>> see > > it as similar to the restricted components -- an icon on the > > processors > > >>> on > > the canvas and the dialog to add components, with additional > > explanation > > (and maybe a target release for full deprecation) in the help notes. > > > > Andy LoPresto > > alopre...@apache.org > > alopresto.apa...@gmail.com > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > On Apr 29, 2017, at 05:16, Andre wrote: > > > > > > dev, > > > > > > In light of the some recent deprecations (ListenLumberjack) and > some > > > potential deprecation (PutJMS/GetJMS) I started some progress on > how > > to > > > document the depreciation of NiFi components using annotations. > > > > > > In the absence of any better name I called the annotation > > > @DeprecationWarning (so not overlap with Java's @Deprecated) > > > > > > The suggested modifications are part of PR#1718 and I am keen to > hear > > your > > > thoughts. > > > > > > While the documentation can be displayed as part of the usage, > > however > > >>> I > > > would imagine the frequency a user browses to the usage pages will > > >>> reduce > > > as her/him becomes familiar with the components. > > > > > > In light of this it may be a good idea to use the web UI to > > highlight > > >>> a > > > processor has been deprecated. > > > > > > Would anyone suggest a way of doing so without disrupting the user > > > experience? > > > > > > Cheers > > > > >>> > > > -- Joseph
nifi-extension-utils
All, As part of NIFI-3724 which was merged to master earlier today, I made some slight refactoring to the organization of some utility code and wanted to mention it in case anyone is wondering where things moved... Previously under nifi-commons we had nifi-processor-utils and nifi-hadoop-utils which had become places to put abstract processors and processor related code. This type of utility code is a bit different from the rest of nifi-commons which is completely independent of anything under nifi-nar-bundles. So I created nifi-extension-utils under nifi-nar-bundles to contain code like abstract processors and things that need to reference controller service APIs. The structure currently looks like the following: nifi-nar-bundles - nifi-extension-utils - nifi-processor-utils - nifi-hadoop-utils - nifi-record-utils - nifi-standard-record-utils - nifi-avro-record-utils - nifi-hadoop-record-utils Going forward the goal would be for nifi-commons to be independent of anything in nifi-nar-bundles. After rebasing you may have the residual projects still under nifi-commons and will want to clean up appropriately. "git clean -dn" will dry run the clean and then "git clean -df" will delete it. Thanks, Bryan
[CALL FOR ACTION] Peer reviews & testing of new code
Dev, Those following the git commit log probably noticed that there has been a lot of action by some of the developers behind some significant improvements in 1.2.0. As these developers get busy I would like to remind the rest of the list about importance of our contribution around code review and *testing* of [proposed] changes to the NiFi code base. So long history short. No matter if you have committer privilege to the NiFi git, you can still contribute to this great community. You can still contribute by providing extra testing of the introduced code (I am myself running SNAPSHOT in prod-like conditions with the new provenance WAL and it is so fast that I reckon you should be doing the same...). You can contribute by helping with the peer review process. [1] So if you have some cycles available and is keen be more active in our vibrant community, feel free to get involved! Cheers! [1] I admit that some of these PRs is daunting to the non-initiated (myself included), but trust me when I say that some are perfectly within reach of those that are familiar with NiFi and have also dealt with things like: HDFS, Azure Cloud, Websockets, etc etc etc. (To be honest, sometimes the contribution may be as simple as spell checking!!)
how to write date to redis
Hello everyone, Now I want write the flowfile data to redis,I use the ExecuteScript processor with python,buth the performance is too low,Who can give me some adviceï¼ Thanks