[
https://issues.apache.org/jira/browse/GROOVY-12433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128538#comment-18128538
]
ASF GitHub Bot commented on GROOVY-12433:
-----------------------------------------
codeconsole commented on code in PR #2949:
URL: https://github.com/apache/groovy/pull/2949#discussion_r4308544702
##########
subprojects/groovy-yaml/build.gradle:
##########
@@ -22,12 +22,12 @@ plugins {
dependencies {
api project(':') // YamlBuilder extends GroovyObjectSupport...
- implementation
"com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:${versions.jackson}"
- implementation
"com.fasterxml.jackson.core:jackson-databind:${versions.jackson}"
- implementation
"com.fasterxml.jackson.datatype:jackson-datatype-jsr310:${versions.jackson}"
+ implementation
"tools.jackson.dataformat:jackson-dataformat-yaml:${versions.jackson3}"
Review Comment:
Keeping Jackson 3's resolution, since this targets 7.0, and documenting it
as a breaking change. It's wider than booleans: Jackson 3.1.6 hard-codes
snakeyaml-engine's `JsonScalarResolver` in `YAMLParser`, so `True`/`FALSE`,
`Null`/`~` and `0x1F`/`017` also become strings, and no feature or
`LoadSettings` schema restores YAML 1.1 resolution. 3702e55 adds
`YamlScalarResolutionTest` pinning the behaviour and a note in the YAML user
guide; the PR description now lists it under breaking changes.
> Move groovy-yaml, groovy-toml and groovy-csv to Jackson 3
> ---------------------------------------------------------
>
> Key: GROOVY-12433
> URL: https://issues.apache.org/jira/browse/GROOVY-12433
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-csv, groovy-toml, groovy-yaml, XML Processing
> Reporter: Scott Murphy Heiberg
> Priority: Major
> Fix For: 7.0.0-alpha-1
>
>
> groovy-yaml, groovy-toml and groovy-csv are built on Jackson 2
> ({{com.fasterxml.jackson}} 2.22.x). Spring Boot 4 uses Jackson 3
> ({{tools.jackson}}) by default, so an application on Spring Boot 4 that uses
> one of these modules carries both major versions and has to manage the
> Jackson 2 one itself. Jackson 2 and 3 use different packages and coordinates,
> so having Jackson 3 on the classpath does nothing for these modules.
> None of the three modules exposes a Jackson type in its public API, so they
> can move to Jackson 3 without source changes for callers.
> Proposal:
> * Depend on {{tools.jackson}} 3.1.6, the version Spring Boot 4.2 manages.
> {{jackson-datatype-jsr310}} is no longer needed; java.time support is built
> into Jackson 3 databind.
> * Build every mapper with {{configureForJackson2()}} so databinding keeps
> Jackson 2's defaults: properties in declaration order, unknown properties
> rejected, nulls for primitives and trailing tokens accepted. The CSV mapper
> also keeps {{SORT_PROPERTIES_ALPHABETICALLY}}, which Jackson 2's
> {{CsvMapper}} enabled itself and the user guide documents.
> * Parser limits follow Jackson 3's defaults: nesting depth 500 (was 1000) and
> string length 100,000,000 (was 20,000,000). Jackson lowered the depth after
> fuzzers reached a StackOverflowError below 1000 (FasterXML/jackson-core#1233)
> and raised the string length for legitimate large payloads
> (FasterXML/jackson-core#1538). {{JsonSlurper}} and {{XmlParser}} keep their
> 1000-level caps.
> * {{XmlParser.parseAs}} and {{parseTextAs}} load jackson-databind
> reflectively; use Jackson 3 when present and fall back to Jackson 2.
> * Jackson 3's YAML backend uses SnakeYAML Engine rather than SnakeYAML, so
> the SnakeYAML alias recipe from GROOVY-12358 needs {{org.yaml:snakeyaml}}
> declared explicitly, as the user guide already anticipates.
> Jackson 3 still uses {{com.fasterxml.jackson.annotation}}, so
> {{@JsonProperty}}, {{@JsonFormat}} and the other annotations in user code
> keep working.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
