Logstash: sync jrjackson & logstash-core-event-java Jackson dependencies versions

[colinsurprenant]

differences in versions constrains between the jrjackson and logstash-core-event-java gems produces jar-dependencies warning messages like

--- jar coordinate com.fasterxml.jackson.core:jackson-annotations already loaded with version 2.7.1 - omit version 2.7.0
--- jar coordinate com.fasterxml.jackson.core:jackson-databind already loaded with version 2.7.1 - omit version 2.7.1-1

we should try to keep both in sync to avoid that. @guyboertje let's update both to the latest which is now 2.7.3 shall we?

[jordansissel]

+1 on getting rid of these warnings by keeping the versions in sync.

[colinsurprenant]

5164 updates logstash-core-event-java to latest jackson 2.7.3.

[guyboertje]

Based on what Christian Meier said, we will forever be updating both to keep them in sync.

It seems the versions are not resolved - first one wins. So if fictitiously, there was another gem, say fancy_yaml that loaded Jackson 2.0.5 via jar_deps - JrJackson and Java Event would be stuck with that (because f < j < l) - not good.

Do you think its worth having a all_logstash_jar_deps gem that defines and loads all of our jar_dependency jars?

[colinsurprenant]

@guyboertje any conflict will be spotted in local dev or through our builds so we can always decide then on the proper solution. Also, I don't think syncing Jackson versions is a big thing either?

Also, as suggested by Christian, we could also lock_jar ? I've never used it, maybe we can see if we can lock to latest Jackson version and force use that instead of relying on load order?

[colinsurprenant]

@guyboertje I just tried jar locking and it works. the only caveat is that it seems that as soon as a Jars.lock files exists, independently of its content, it stops outputting the dependencies versions warnings. I am investigating.

[colinsurprenant]

Yup, confirmed. reported issue mkristian/jar-dependencies/issues/46
Not a blocking issue but would be a nice fix.

[jordansissel]

I'm marking this a blocker. The reasoning is we have bug reports from users asking about problems because of similar messages -- by similar, I mean messages that have the following properties:

1. the message is not actionable for the user
2. the message is confusing to the user
3. the message is not something caused by the user

When we have output to a user with the above properties, history has shown that this causes bad user experience. We can't ship with this kind of message.