Jackson versioning can at times be quite fragmented. New versions often patch security issues, so it'd be best if users standardize on a known set of versions. Yet, how to exactly enforce a certain version can depend on a number of different factors.
if the Jackson BOM is used, updating that is the best bet
and then likely, only rely on BOM managed versions and remove any overridden versions
and again, only rely on managed versions; remove any overridden versions
if there are explicitly versioned Jackson dependencies
one might want to add the Jackson BOM
or at least consistently version the dependencies
... other cases ??
Perhaps it would be good to start a Yaml aggregation of recipes that covers each of these separate use cases to consistently version Jackson in a project, depending on the context. This could then evolve to continuously patch Jackson version as appropriate.
Jackson versioning can at times be quite fragmented. New versions often patch security issues, so it'd be best if users standardize on a known set of versions. Yet, how to exactly enforce a certain version can depend on a number of different factors.
jackson-bom.version
to actually use the latest version; as it can lag behindPerhaps it would be good to start a Yaml aggregation of recipes that covers each of these separate use cases to consistently version Jackson in a project, depending on the context. This could then evolve to continuously patch Jackson version as appropriate.