Joe, I decided to just drop it and move it over to my private repo here:
https://github.com/MikeThomsen/nifi-datageneration-bundle There it's part of a much bigger bundle focused on using NiFi for test data generation. Thanks, Mike On Thu, Aug 30, 2018 at 4:38 PM Joe Witt <[email protected]> wrote: > 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? >
