nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: Should I withdraw this PR?
Date Thu, 30 Aug 2018 20:38:17 GMT

I'd say there are a couple of options.

1) Don't add the nar to the nifi-assembly.  Leave the source in there.
It still gets built.  Just dont bundle the nar in the resulting build
by default.  You could have a profile based activation to include it
like is done for hive3 i believe - for example.  If you do this you
also dont need any of the licensing/notice impacts to show up in the

2) Don't merge at all.  Keep this outside of the project in its own
github repo.  Provide instructions on how to build, include in nifi,
and make a great blog on how it can be used to test nifi record
oriented flows/configurations/etc.  Going this route means it is
outside the community but still useful and helpful to the community.

I haven't looked into it in detail to know how big it is nor how
configurable/capable it is for generating useful sample data for
exercising record processors and configurations.  So, i dont have a
strong preference/understanding relative to which of the above options
is best.  I'd defer to you or folks that reviewed more closely.

On Wed, Aug 29, 2018 at 3:55 PM Mike Thomsen <> wrote:
> I have been building a bundle that complements it. Repo is here:
> Joe raised a valid point in the PR about us being space-constrained in the
> assembly, and so I'm wondering if I should just move it over to that repo
> and point the Jira ticket to it.
> Thoughts?

View raw message