[
https://issues.apache.org/jira/browse/METRON-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673141#comment-16673141
]
ASF GitHub Bot commented on METRON-1815:
----------------------------------------
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1249
The common should have all the interfaces, base classes and utilities.
The parsers should only have the parsers.
In 777 I left the Grok, JSON, CSV in common, and only had the derived split
out. I don't think that is necessary, but we may want to think about it from a
library design pov. Why would I have to use both metron-parsers and
metron-parsers common just to create my own grok derivative for example.
I think that the idea should be " a third party should never have to depend
on metron-parsers unless they are deriving from a specific parser type - ASA,
YAF, BRO. Deriving from a 'base format type' ( GROK, csv, json, syslog ) only
requires dependency on common"
> Separate metron-parsers into metron-parsers-common and metron-parsers-storm
> ---------------------------------------------------------------------------
>
> Key: METRON-1815
> URL: https://issues.apache.org/jira/browse/METRON-1815
> Project: Metron
> Issue Type: Improvement
> Reporter: Justin Leet
> Assignee: Justin Leet
> Priority: Major
>
> In order to expose our parsers to 3rd party components (e.g. the discussions
> on NiFi and potentially other platforms like Spark), we should
> separate the storm-bits into its own project. The metron-parsers-common
> project should contain only parser-oriented code, whereas the
> metron-parsers-storm project should contain the storm specific code
> (e.g. the parser bolt).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
