Mike 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 nifi-assembly/L&N. 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. Thanks On Wed, Aug 29, 2018 at 3:55 PM Mike Thomsen <[email protected]> wrote: > > https://github.com/apache/nifi/pull/2813 > > I have been building a bundle that complements it. Repo is here: > > https://github.com/MikeThomsen/nifi-datageneration-bundle/ > > 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?
