I support option 1 if Infra will do it. Otherwise 2. But it might be easier
to achieve the Infra request after we have exited the incubator.
--Matt
On 3/27/17, 6:25 PM, "zeo...@gmail.com" <zeo...@gmail.com> wrote:
I don't have a strong opinion here, but I'm interested to see what the
direction on this one will be. </bump>
Jon
On Wed, Mar 22, 2017 at 3:30 PM Otto Fowler <ottobackwa...@gmail.com> wrote:
> As we have discussion previously, I am working on a plugin architecture
for
> parsers and stellar ( down the road ), base on Nifi’s Nar format.
>
> Part of using the Nar system is building the Nar itself. This is done
> using the nifi-nar-maven-plugin. Some historical background - this plugin
> used to live in the nifi
> repo/tree, and they split it out to it’s own repo and published it to
> apache mvn.
>
> For Metron’s use of the nar we want the following:
>
> 1. To be able to change the archive’s extension from .nar to something
else
> specific for us
> 2. To be able to rename the manifest information generated so that it
> doesn’t reference nar
> 3. Possibly to be able to add more manifest entries and custom metron
> specific metadata
>
> My first preference, was to use the nifi plugin as is, but with just
enough
> modification to make
> points 1 and 2 possible.
>
> To that end I opened a jira and submitted a PR to the nifi project that
did
> just that, added the ability to configure the type produced by the plugin
> and set the metadata prefix name.
>
> The chair of nifi, has commented that issue suggesting that we fork or
copy
> the plugin, since he has rightly noticed that there is really no benefit
> for
> them in accepting these changes and capabilities.
>
> I wanted to have a discussion around what I see as the options we have at
> this point..
>
> 1. As Nifi did, we request a new git repo to host our version of the
> plugin, and do a release/publish of the plugin to apache mvn. This would
> include ‘rebranding’ the plugin
> from nifi to something else.
> 2. We start as they did, with the plugin with my changes and as a separate
> build step ( copy )
> 3. We fork and use git submodules to track that project
>
> In cases 2 or 3 we will have to decide to rebrand or just use a custom
> version scheme ( -METRON ) with the plugin.
>
> To me, option 1 is the best option, although it will involve me getting
> help from others to accomplish ( INFRA request, release manager etc etc ).
> But, it is the cleanest, best option I think for a production case.
> Thoughts?
>
>
>
>
>
>
>
> for reference:
> https://issues.apache.org/jira/browse/NIFI-3628
> https://github.com/apache/nifi-maven/pull/2
>
>
http://mail-archives.apache.org/mod_mbox/nifi-dev/201508.mbox/%3CCALJK9a7xJW%2BG-dJSXAZ640xQdy4tpRZ%3DtEuHDgq8A%3DMY%2BOkf1g%40mail.gmail.com%3E
> https://issues.apache.org/jira/browse/INFRA-10119
>
--
Jon
