Repackaging Jackson package breaks Jackson annotations about java-jwt

[pose]

Hi @hexangular,

Unfortunately, people using our library could be using a different Jackson version (this was the case why we decided to merge this change, see #6). I agree is not elegant repackaging but how would you address having different versions of Jackson? Do you think there is a better and more elegant way to tackle the issue?

Thanks in advance,

[kucharzyk]

Hi @pose ,

Maybe can You provide some kind of adapter for users and remove Jackson from dependencies.
Adapter interface would have all serialization/deserialization methods and user would implement it using his version of Jackson or maybe even using different library.

It would require a liite more work from users but I think It can be a solution.

What do You think?

[pose]

Hi @hexangular,

One of the guiding lights of java-jwt is making the library simple to use. That means that we should provide a default JSON serialization/deserialization mechanism in the library. I agree with your point of creating an Adapter Interface as long as is clear and doesn't add much complexity or too many abstractions but by default it should work as it does now.

Maybe there is another way to solve this: What if we use optional dependencies in Maven? I'm thinking something like, if you include GSON or your own JSON library we use that but if we don't find it we switch to our default. One of the drawbacks would be that those checks could be expensive as they use reflection. Thoughts?

[thaggie]

Or you could provide multiple binaries and let consumers decide whether or not to have things repackaged.

[cowtowncoder]

Couple of comments here, in case they might help.

First, while it makes sense to repackage some of Jackson code (like streaming parser/generator, jackson-core and databinding, jackson-databind), it may not make as much sense to repackage annotations under com.fasterxml.jackson.annotation. That package is much more static and slow moving, and rarely causes version conflicts. So perhaps leaving annotations package in its original Java package would be the best way? This would allow working with both vanilla Jackson 2.x and repackaged version(s).

Second: all access to annotations by Jackson is via abstract (AnnotationIntrospector), so it is actually possible to add support both for "alien" annotations (like JAXB), old versions (use Jackson 1.x annotations with Jackson 2.x) and repackaged variants. Not sure if this helps here -- probably not? -- but perhaps worth mentioning.