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