metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <ma...@apache.org>
Subject Re: [DISCUSS][PROPOSAL] Maven Plugin to build packages with dependencies
Date Tue, 28 Mar 2017 17:00:40 GMT
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
    



Mime
View raw message