[
https://issues.apache.org/jira/browse/METRON-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041090#comment-16041090
]
ASF GitHub Bot commented on METRON-777:
---------------------------------------
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/530
@nickwallen I did consider staging the PR's close to what you suggested at
various points ( this is my 3rd re-write of this functionality ( Ansible + just
packages, RPM + just packages, RPM + NAR/Bundle ).
I was however concerned with submitting a small PR, which didn't break the
PR master build/functional requirements, yet had enough context to be
reviewable and worth reviewing. And writing a parallel deployment/rpm/ambari
install did not seem like a good idea. My understanding was and is that each
PR should be fully functional by the PR criteria. Thus I broke it up as I did
between capabilities and user facing.
From your breakup:
1) would have had to have been just the NAR stuff, out of context
2) **was** split out as METRON-942 in a sense.
3-4) cannot be done separately while maintaining a working metron
If we were at the beginning, and had discussed the feature branch etc, I am
sure we would progress that way and deal with the broken builds and have the
reviewable chunks.
But we are not. I will do whatever I can to address concerns and move this
along, I am not sure that the effort to rework this and the dependent branches
( which would be quite a bit of work at this point ) is worth while.
> Create a plugin system for Metron based on 'NAR'
> ------------------------------------------------
>
> Key: METRON-777
> URL: https://issues.apache.org/jira/browse/METRON-777
> Project: Metron
> Issue Type: New Feature
> Reporter: Otto Fowler
> Assignee: Otto Fowler
>
> The success of the Metron project will be greatly dependent on community
> participation, and with that the ability to adapt and extend Metron without
> having to maintain a fork of the project.
> As organizations and individuals look to extend the Metron system with custom
> parsers, enrichments, and stellar functions that may be proprietary in
> nature, the ability to develop and deploy these extensions outside the Metron
> code base is critically important.
> To that end, and after community discussion and proposal we create or
> formalize the 'plugin' development story in Metron.
> The proposal is to adapt the Apache Nifi NAR system for use in Metron. This
> will provide the system with:
> * archetype(s) for developer projects and independent development
> * defined packaging and metadata for 'plugin' products
> * loading and instantiation with classloader isolation capabilities
> * removing the necessity for shading plugin jars
> These capabilities will also enable other features, such as plugin lifecycle,
> plugin configuration+redeployment, and other things.
> The plugin archetypes and their installation will be a followon
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
