metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Subject Re: Metron Rest - where is reflections coming from?
Date Tue, 07 Mar 2017 19:51:23 GMT
btw :)

I followed you instructions, assumed it was a module level dependency and I
seem to be OK now.

On March 7, 2017 at 10:34:31, Ryan Merriman ( wrote:

I have a good understanding of this since I spent a good amount of time
troubleshooting it. Let me attempt to explain it. Hopefully if everyone
clearly understands the core issue we can put our heads together for a

The metron-common module shades guava and is installed as an uber jar (all
dependencies included) instead of a regular jar (only metron-common code).
Now consider that metron-rest has a dependency on org.reflections.
Normally you would add a dependency in the metron-rest pom stating the
version you need and Maven would figure it out. But in this case Maven
includes both the org.reflections jar and metron-common uber jar (because
that's what's installed) in the classpath when building metron-rest. The
problem is now we have 2 different versions of org.reflections in the
classpath: a normal one and one whose guava dependencies have been
shaded. The easiest solution (and the one that is currently being used) is
to just not directly include the normal version and let metron-rest use the
version that comes with metron-common. The metron-rest module simply calls
the org.reflections classes and doesn't care which version of guava (shaded
or not) org.reflections depends on.

The reason Intellij has a problem with this is that it doesn't include the
metron-common jar installed in the local Maven repo (like mvn package
would), instead it includes the Intellij metron-common module. This is how
Intellij works and reimporting the project will not help. The workaround
for Intellij is this:

1. Navigate to Project Structure > metron-rest > Dependencies
2. Add a new dependency of type Library
3. Create a new Library of type Java
4. Select

5. Apply

I can think of a couple solutions for this with varying degrees of

- We could replace org.reflections in metron-rest with something else.
Probably the option with the lowest effort.
- We could not use guava in metron-common, removing the need to shade
it. I don't think this is even an option because guava is all over the
place and would take a lot of effort to remove.
- Move hbase-client dependency out of metron-common. This is the cause
of our guava problems right? HBase uses an old version that conflicts with
never versions. This would likely take some experimenting but the end
result could make things a lot easier in general. Right now depending on
metron-common is difficult and it shouldn't be. It's common code.

Hopefully this helps. I will continue brainstorming. Keep in mind that
this issue is not confined to metron-rest, any module depending on
metron-common could be impacted by this.

On Tue, Mar 7, 2017 at 7:39 AM, Casey Stella <> wrote:

> It should get it from Metron common and IntelliJ is showingnme the same
> issue. I'm baffled by it, slightly. Maven builds just fine, so who knows.
> Its on my list of oddities to look at post-vacation.
> On Tue, Mar 7, 2017 at 12:57 Otto Fowler <> wrote:
> >
> >
> metron-interface/metron-rest/pom.xml
> >
> > I don’t we where the dependency for reflections is being set, and my
> build
> > is failing. Am I missing something post merge?
> > Is it an intellij thing?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message