I've also heard something about a big change to the way relationships work.
Maybe grouping relationships into larger groupings "failure" as a parent, with
multiple optional/fine grained, children. Something like that. If that rings a
bell, maybe add it to your list 😊.
-Original Message
It makes sense there would be an mvp set of registry capability and thus a
dependency for nifi 2.0 on registry readiness/version. Otherwise I would
largely hope not.
On Fri, Jun 14, 2019 at 1:29 PM Otto Fowler wrote:
> Will that effort or planning be across all the nifi projects? minifi / cpp
Will that effort or planning be across all the nifi projects? minifi / cpp
/ registry etc?
On June 14, 2019 at 13:01:36, Joe Witt (joe.w...@gmail.com) wrote:
Peter,
Yeah I think we're all circling around similar thoughts on things which are
'best for a major release' and we need to start codif
Peter,
Yeah I think we're all circling around similar thoughts on things which are
'best for a major release' and we need to start codifying that. At the
same time we need this to be focused on items which can only reasonably
happen in a major release and not become a new kitchen sink for
JIRAs/i
I'm not sure I totally follow... is there a reason that the token
methods in NiFIClient can't be used?
I would expect that it is the CLI's decision whether to call
getXYZForProxiedEntities or getXYZForToken.
The client factories in CLI currently wrap the client and force the
use of proxied entiti
I've seen a lot of comments along the line of, "I don't think this will happen
before NiFi 2.0". Do we have a roadmap/list somewhere of the big general
changes planned for NiFi 2.0 or some kind of 2.0 roadmap?
--Peter
Turns out there isn't going to be an easy way like I thought. Looking at
everything it seems to me that you can generalize all the different jersey
clients as with headers or without headers. Currently they all support this as
a way to implement proxies that the Client Factory wraps things at cr
