ByteBuddy scope went beyond test in version 2.17.0

[migmruiz]

It seems to me that this was a mistake introduced here
https://github.com/FasterXML/jackson-databind/pull/4254/files/

Originally posted by @migmruiz in #4254 (comment)

[JooHyukKim]

Makes sense. Filed PR #4429 to address this. Thanks @migmruiz!

[cowtowncoder]

UGH. ... and no one noticed/reported this during 2.17.0-rc1. Next time I think it might be best to avoid rc-phase altogether as we keep missing significant problems anyway.

Thank you @migmruiz for reporting this.

[cowtowncoder]

Fixed for 2.17.1.

[yihtserns]

UGH. ... and no one noticed/reported this during 2.17.0-rc1.

Because users have no reason to suspect a new dependency that is not obviously test-only e.g. Mockito or JUnit? It is not like Byte Buddy is a lib that exists only to exclusively help in writing tests anyway e.g. Hibernate uses it. 🤷

I'm guessing @migmruiz noticed it either because he works in a place where every new lib needs justification, or this version of Byte Buddy caused version conflict in his project?

[cowtowncoder]

Ahhh. Very good point that ByteBuddy is NOT regularly test(-only) dependency.
And I can see how for most users added unexpected dependency is hidden by tooling; besides, addition might have been intentional indeed.

Still all that said, I am disappointed that this was not caught and reported before .0 release -- consider the fact that right after 2.17.0 was released this was reported within 24 hours. So my point has more to do with vast difference of reports from "final" minor release vs. any of release candidates: this has been recurring theme. Not just this specific thing, but rate of issue reporting.

[norrisjeremy]

How soon will 2.17.1 be released so that ByteBuddy is no longer pulled in as a transitive dependency?

[pjfanning]

How soon will 2.17.1 be released so that ByteBuddy is no longer pulled in as a transitive dependency?

If you read the comments, you will see that we believe that this is easily worked around. Every build tool that I am aware of has a way to exclude transitive dependencies.

[norrisjeremy]

How soon will 2.17.1 be released so that ByteBuddy is no longer pulled in as a transitive dependency?

If you read the comments, you will see that we believe that this is easily worked around. Every build tool that I am aware of has a way to exclude transitive dependencies.

I'm fully aware of that. But having to manually go thru tens of projects to add an exclusion that we would then turn around and remove after the next release is extremely tedious.
All I was asking was if you had a projected date as to when 2.17.1 would be released, so our team can evaluate if it's worthwhile to go through this exercise, or simply wait.

[pjfanning]

How soon will 2.17.1 be released so that ByteBuddy is no longer pulled in as a transitive dependency?

If you read the comments, you will see that we believe that this is easily worked around. Every build tool that I am aware of has a way to exclude transitive dependencies.

I'm fully aware of that. But having to manually go thru tens of projects to add an exclusion that we would then turn around and remove after the next release is extremely tedious. All I was asking was if you had a projected date as to when 2.17.1 would be released, so our team can evaluate if it's worthwhile to go through this exercise, or simply wait.

There is no plan to release 2.17.1 yet. One option is to revert to 2.16.2.

[cowtowncoder]

@norrisjeremy Timeline depends on balance between number of fixes to get int vs urgency of getting specific high priority fixes out: given it takes 2.5 - 4 hours to do full release (like 2.17.1), this wouldn't yet qualify for doing 2.17.1 this week (for example).
The first .1 patch release typically gets released 4 - 8 weeks after the .0 release, so I think we'll get 2.17.1 out likely around mid-April. Unless something urgent comes up before that.

I hope this helps.

[chadlwilson]

To help people out, if you want to do this globally in one of the Gradle-canonical ways:

For simpler cases this will often do

dependencies {
  implementation('com.fasterxml.jackson.core:jackson-databind:2.17.0') {
    exclude(module: 'byte-buddy') // Workaround https://github.com/FasterXML/jackson-databind/issues/4428 until Jackson 2.17.1
  }
}

For more complex projects with api dependencies, multi-project builds and things where exclusions are evaluated in different contexts, you can apply this kind of component metadata rule "hammer" to your dependencies blocks (or add the same components block to settings.gradle's dependencyResolutionManagement block.

dependencies {
  components {
    // Workaround https://github.com/FasterXML/jackson-databind/issues/4428 until Jackson 2.17.1
     withModule('com.fasterxml.jackson.core:jackson-databind', { details ->
      details.allVariants { withDependencies { removeAll { it.name == "byte-buddy" } } }
    })
  }
}

[cowtowncoder]

Thank you for sharing, @chadlwilson !