metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zeolla@GMail.com" <zeo...@gmail.com>
Subject Re: [DISCUSS][PROPOSAL] Maven Plugin to build packages with dependencies
Date Tue, 28 Mar 2017 19:52:04 GMT
I'm game for that

On Tue, Mar 28, 2017, 1:19 PM Matt Foley <mattf@apache.org> wrote:

> Makes sense.
>
>
>
> From: Otto Fowler <ottobackwards@gmail.com>
> Date: Tuesday, March 28, 2017 at 10:13 AM
> To: "dev@metron.incubator.apache.org" <dev@metron.incubator.apache.org>,
> Matt Foley <mattf@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 (mattf@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, "Zeolla@GMail.com" <zeolla@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 <ottobackwards@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message