Repository artifact for non-shaded MrBean dependency

[TuomasKiviaho]

ByteBuddy already shades the usually no so backward compatible ASM and I'd really with to be able to utilize ByteBuddy's latest fixes with MrBean in the future. Would it be possible to get rid of the shading all-to-gether and trust ByteBuddy to do the job properly or at least have a non-shaded version of the library available as well. I don't think that having ByteBuddy shaded (and therefore having ASM re-shaded) is beneficial and I believe this is just a leftover from the transition.

PS. To me it's not an issue which of the .jars is the default one but since it's a major release, perhaps the shaded one should actually be the one behind classifier.

PPS. I wonder why ByteBuddy doesn't provide a I-know-what-I'm-doing variant of the .jar. Only the shaded one is available. This should not be an issue since ASM isn't directly used anymore or is it. If it is then I'd would've been nice to have non-shaded versions of both of the libraries and have the shading done once for both. This would of course render the non-shaded version quite useless due to ASM being known to backward compatible in quite error prone way, but I trust that everything is done or could be done via ByteBuddy

Edit: There is a byte-buddy-dep version of the library that doesn't have any shaded libs in it.

[cowtowncoder]

Since ByteBuddy is only used for 3.0 I think it'd be fine to leave out shading.

One question though: so is the main problem here that when it's shaded, you can not upgrade to a later ByteBuddy version easily? If so, there is the balance between potential breakage across versions (ByteBuddy seems like a great library, but it won't be immune to all the usual problems with highly popular transitive dependency) vs access to later better versions.

[TuomasKiviaho]

One question though: so is the main problem here that when it's shaded, you can not upgrade to a later ByteBuddy version easily?

That's correct and ByteBuddy also has had it's fair share of sometimes surprising API changes. My über .jar already contains a ByteBuddy and I'm just preparing for the time when 3.x comes. #63 also mentions IdentityClassLoader proposal which would only work without shading or then I'd need start using the shaded one myself.

Shading is a quick way to avoid problems but since OSGi for instance allows me to embed a 3rd party library it's actually more of a hindrance when IDE shows me multiple classes with same identical names. Sometimes the shadings don't even come with javadoc/sources attached so debugging of the shadings also requires me to "go in blind".

I'd be happy with a jackson-module-mrbean-dep variant (bytebuddy pom I believe contains all the magic needed to produce such) that would allow me to share the lib, but I believe that a shaded version is still preferred by the majority and ASM being shaded twice can be avoided by MrBean depending on the byte-buddy-dep and it's transitives.

[cowtowncoder]

@TuomasKiviaho forgot to follow-up here but I'd be happy to merge a PR for changes to unshade ByteBuddy in 3.0. Decision could still be reversed but our direction has been to try to reduce shading.