[jira] [Commented] (METRON-48) make metron modular with OSGi or Jigsaw or...?

["Casey Stella (JIRA)" <ji...@apache.org>]

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

Casey Stella commented on METRON-48:
------------------------------------

Ran into the guava and dependency issues too.  If you look Metron-Common's pom, we've started to relocate aggressively deprecating dependencies such as guava.  This creates a stable base for us to depend on, because as the maven shade plugin builds the jar, it'll rewrite the bytecode.  This is the same technique that Storm uses (see lines 536+ at https://github.com/apache/storm/blob/master/storm-core/pom.xml).

Right now Guava is the only jar that we're doing that for, but we'll probably do it for others.  Is there other concerns outside of classpath conflicts?

Moving to OSGi sounds like quite a bit of core work and I'd like to know more about what exactly we get for it before endeavoring into that adventure.  Do you have any idea if there is a performance impact?  If so, how much would we be looking at?

> make metron modular with OSGi or Jigsaw or...?
> ----------------------------------------------
>
>                 Key: METRON-48
>                 URL: https://issues.apache.org/jira/browse/METRON-48
>             Project: Metron
>          Issue Type: Improvement
>         Environment: any
>            Reporter: Charles Porter
>   Original Estimate: 1,344h
>  Remaining Estimate: 1,344h
>
> The large number of dependencies and transitive dependencies make it very difficult or impossible to be sure that there are no conflicts in libraried. For example, hBase 1.1 currently depends on guava 1.7 or lower, but ElasticSearch 2.1.x depends on guava 1.8 or higher. This means it is impossible to build Metron so it satisfies both requirements. 
> The above is meant only as an illustration, because it is an issue I have seen. I have worked around this in my current project, but the work-around is ugly.
> The correct solution is a modularization system, allowing bolts and spouts to _each_ run in their own classloader.   We could roll our own solution or use OSGi (or Jigsaw, if it existed)
> Perhaps the right place to solve this is in Storm, since storm controls classloading.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)