[ 
https://issues.apache.org/jira/browse/METRON-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103920#comment-16103920
 ] 

ASF GitHub Bot commented on METRON-777:
---------------------------------------

Github user ottobackwards commented on the issue:

    https://github.com/apache/metron/pull/530
  
    WRT: Required Bundle dependency for BundleProvidedDependenciesMojo.
    
    That mojo is not run automatically, either in metron or in the nifi case.  
It is *explicitly* run to determine the dependencies of a bundle dependency, 
i.e.:
    
    ```xml
    <dependencies>
      <dependency>
        <groupid>org.apache.metron</groupid>
        <artifactid>metron-hbase-common-bundle</artifactid>
        <version>0.4.1</version>
        <type>bundle</type>
      </dependency>
    <dependencies>
    ```
    Running it against projects without bundle dependencies *would* be an error.
    
    I think this is ok.
    
    
    



> 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.4.14#64029)

Reply via email to