metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Subject [DISCUSS][PROPOSAL] Maven Plugin to build packages with dependencies
Date Wed, 22 Mar 2017 19:30:34 GMT
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.

for reference:

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