I'm game for that On Tue, Mar 28, 2017, 1:19 PM Matt Foley <ma...@apache.org> wrote:
> Makes sense. > > > > From: Otto Fowler <ottobackwa...@gmail.com> > Date: Tuesday, March 28, 2017 at 10:13 AM > To: "dev@metron.incubator.apache.org" <dev@metron.incubator.apache.org>, > Matt Foley <ma...@apache.org> > Subject: Re: [DISCUSS][PROPOSAL] Maven Plugin to build packages with > dependencies > > > > I am going to proceed on with 2. > > It is prudent to stand review and criticism before involving > infrastructure. > > > > > > > > On March 28, 2017 at 13:00:46, Matt Foley (ma...@apache.org) wrote: > > 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 > > > > -- Jon
