I actually do it manually in docker file:
RUN mv /opt/nifi/nifi-current/lib/*.nar /opt/nifi/nifi-current/lib.original/
RUN cp /opt/nifi/nifi-current/lib.original/nifi-avro-nar-$NIFI_VER.nar
/opt/nifi/nifi-current/lib
RUN cp
/opt/nifi/nifi-current/lib.original/nifi-update-attribute-nar-$NIFI_VER.na
That would be a fine option for those users who are capable to run maven
builds. I think evolving the nifi registry and nifi integration to source
all nars as needed at runtime from the registry would be the best user
experience and deployment answer over time.
Thanks
On Mon, Jun 29, 2020 at 9:57
As far as I can tell, Kylo is dead based on their public github activity.
Mark,
Would it make sense for us to start modularizing nifi-assembly with more
profiles? That way people like Boris could run something like this:
mvn install -Pinclude-grpc,include-graph,!include-kafka,!include-mongodb
O
Hi Mark, thanks for the great comments and for working on these
improvements. these are great enhancements that we
can certainly benefit from - I am thinking of two projects at least we
support today.
As far as making it more user-friendly, at some point I looked at Kylo.io
and it was quite an int
Hey Boris,
There’s a good bit to unpack here but I’ll try to answer each question.
1) I would say that the target audience for NiFi really is a person with a
pretty technical role. Not developers, necessarily, though. We do see a lot of
developers using it, as well as data scientists, data engi
Hi guys,
I am thinking to increase the footprint of NiFi in my org to extend it to
less technical roles. I have a few questions:
1) is there any plans to support easy dependencies at some point? We are
aware of all the current options (wait-notify, kafka,
mergerecord/mergecontent etc.) and all of
