Should I withdraw this PR?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Should I withdraw this PR?

Mike Thomsen
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?
Reply | Threaded
Open this post in threaded view
|

Re: Should I withdraw this PR?

Joe Witt
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 <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Should I withdraw this PR?

Mike Thomsen
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 <[hidden email]> 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 <[hidden email]>
> 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?
>