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

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

Github user ottobackwards commented on a diff in the pull request:

    https://github.com/apache/metron/pull/530#discussion_r120786253
  
    --- Diff: 
bundles-lib/src/test/java/org/apache/metron/bundles/integration/components/MRComponent.java
 ---
    @@ -0,0 +1,68 @@
    +/**
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +
    +package org.apache.metron.bundles.integration.components;
    +
    +import org.apache.hadoop.conf.Configuration;
    +import org.apache.hadoop.fs.Path;
    +import org.apache.hadoop.hdfs.MiniDFSCluster;
    +import org.apache.hadoop.yarn.conf.YarnConfiguration;
    +import org.apache.metron.bundles.integration.InMemoryComponent;
    +
    +import java.io.IOException;
    +
    +public class MRComponent implements InMemoryComponent {
    --- End diff --
    
    So, as mentioned above - the idea at the start was to create something that 
make end up being a new shared library between NiFi and Metron down the road.  
Now, I didn't hold my own feet to the fire on that, but there are some areas 
where that thinking comes through.  This is one.  I did not want to create 
dependencies between bundle-lib and any metron libs.  So, where necessary I 
created copies.  I know this isn't great, and the original goal may just be 
fantasy, but that is why.


> 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)

Reply via email to