nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Parisi <phroc...@apache.org>
Subject Opinions on Assembly target location
Date Wed, 27 Feb 2019 16:43:51 GMT
Hi ,
   I've submitted a PR to Apache NiFi MiNiFi C++ that enables the project
to access and run NiFi processors. This requires that certain jars be
included to bootstrap that process long with a set of NARs from which we
will access the desired components. Effectively this means that a user can
run the current set of C++ processors alongside Java processors.
   To facilitate this feature's use, I submitted a PR [1] to NiFi with that
assembles the appropriate JARs and a basic set of useful/necessary NARs.
I'd like opinions on where this should live. The options have been to place
it within Apache NiFi MiNIFi C++ ( specifically within the aforementioned
feature's build directory) as it only relates to that project and, perhaps
allowing us to more easily address problems...or as per the PR: placing it
in NiFi proper, hopefully building regression tests that notify us of
issues before a release.

   I've been wavering on the options and want community opinion. The end
goal in either case is that if/when a user builds with this functionality
we can deliver a package that runs out of the box. This can be done with
either approach.

    The net positive of placing it in NiFi as I see it: sense that it is an
official feature and perhaps notification before NiFi release or in
travis.  Side effects include: questioning if this belongs here, hair loss,
and perhaps a sudden loss of appetite.

    The net positive of isolating this within MiNIFi C++: cleaner end
solution, it's produced in the same place it's consumed, ability to notify
of problems in our CI and release process ( this could be viewed as a
negative too ? ).

TL;DR:  Where feature Live?

    Any insight/opinions are appreciated. Thanks!

[1] https://github.com/apache/nifi/pull/3330

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message