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:19:25 GMT
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 




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