Update jackson-core to 2.11.4

[scala-steward]

Updates com.fasterxml.jackson.core:jackson-core from 2.11.3 to 2.11.4.

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

Files still referring to the old version number

The following files still refer to the old version number (2.11.3).
You might want to review and update them manually.

daffodil-cli/bin.NOTICE

Ignore future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "com.fasterxml.jackson.core", artifactId = "jackson-core" } ]

labels: library-update, semver-patch, old-version-remains

[tuxji]

+1

The change itself looks fine. I canceled one of the 7 checks because it was hanging during the Rat check. The Rat check seems to hang sporadically during the last CI build on Windows until canceled automatically or manually.

[mbeckerle]

I would like us to have a wiki page on our confluence discussing the review criteria for these automated updates. I.e., a checklist of what we should be ckecking on to convince ourselves that one of these upgrades is acceptable.

[stevedlawrence]

Agreed, I'll create a page.

[tuxji]

I agree we need a checklist. I just realized I overlooked that daffodil-cli/bin.NOTICE still mentions jackson-core's old version number. The review criteria should include:

1. A determination whether the version update is a patch, minor, or major update. Major updates need more stringent review criteria than the other updates, at least a manual reading of the library's release notes / changelog to check for API changes.

2. How to update any files like daffodil-cli/bin.NOTICE. Should we push a commit to each and every pull request updating that page AND squash the commits together before merging each pull request? Or update the daffodil-cli/bin.NOTICE file once in one last manually made pull request?

[stevedlawrence]

I've created this page as a starting point for documentation:

https://cwiki.apache.org/confluence/display/DAFFODIL/Scala+Steward

Feel free to add anything if I missed anything.

I also added a way I suggest we make changes, which is exactly the same as our normal work flow except any changes are pushed to the appropriate branch on the scala-steward/daffodil fork rather than our own fork. I perfer it done this way (one for every fork) so that the version bump and any related changes (e.g. API updates, license changes) are in the same commit. This might be a bit of a pain for this first go around, but hopefully things haven't changed their licenses. And once we get through this big set, it should be easier to keep up with it.

[stevedlawrence]

Another thought, we might want to update our LICENSE/NOTICE files to say something like foo-<VERSION>.jar or foo-*.jar so that we don't need to update the LICENSE/NOTICE file for every version bump. That's a bit of a pain, and I'm not sure we gain much extra by including specific jar versions in these files.

[tuxji]

Yes, let's replace the explicit version numbers in LICENSE/NOTICE files with foo-<VERSION>.jar to reduce the number of times we need to update our LICENSE/NOTICE files manually to only whenever the library changes its own LICENSE.

I found a problem with the first git command in the Confluence page https://cwiki.apache.org/confluence/display/DAFFODIL/Scala+Steward. I logged into Confluence (I have an account with the username "interran" and name "John Interrante") but I don't have the ability to edit the page or add a comment to it so I will have to suggest the correction here. The first git command adds the wrong repo URL as the remote URL (right now it adds Scala Stewart's own github repo as the url, not Scala Stewart's github fork of the Daffodil repo). Please change it to:

git remote add scala-steward git@github.com:scala-steward/daffodil.git

Note I'm not sure if we will have permission to push a commit to the Scala Stewart fork, but let's find out.

[stevedlawrence]

@tuxji I've given you full permissions to the wiki.

Also, GitHub has a feature that lets owners of a repo to push to fork branches that have been submitted as pull requests as long as the pull request creator allows it (which is the default). Scala steward allows this, so we should be able to push to their daffodil fork.

[tuxji]

We don't HAVE to mention the branch name in BOTH the second and third git commands in the Confluence page. We could simply fetch from all our upstream repos and only then say which branch we want to check out:

interran@GH3WPL13E:~/apache/daffodil-asf$ git fetch --all
Fetching origin
Fetching scala-steward
remote: Enumerating objects: 53, done.
remote: Counting objects: 100% (53/53), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 55 (delta 40), reused 53 (delta 40), pack-reused 2
Unpacking objects: 100% (55/55), 12.81 KiB | 184.00 KiB/s, done.
From github.com:scala-steward/daffodil
 * [new branch]          master                           -> scala-steward/master
 * [new branch]          runtime2-2202                    -> scala-steward/runtime2-2202
 * [new branch]          update/Saxon-HE-9.9.1-8          -> scala-steward/update/Saxon-HE-9.9.1-8
 * [new branch]          update/icu4j-68.2                -> scala-steward/update/icu4j-68.2
 * [new branch]          update/jackson-core-2.11.4       -> scala-steward/update/jackson-core-2.11.4
 * [new branch]          update/jansi-1.18                -> scala-steward/update/jansi-1.18
 * [new branch]          update/junit-4.13.2              -> scala-steward/update/junit-4.13.2
 * [new branch]          update/sbt-1.4.8                 -> scala-steward/update/sbt-1.4.8
 * [new branch]          update/sbt-native-packager-1.7.6 -> scala-steward/update/sbt-native-packager-1.7.6
 * [new branch]          update/scala-library-2.12.13     -> scala-steward/update/scala-library-2.12.13
 * [new branch]          update/scalacheck-1.15.3         -> scala-steward/update/scalacheck-1.15.3
 * [new branch]          update/scallop-4.0.2             -> scala-steward/update/scallop-4.0.2
 * [new branch]          update/typesafe-1.4.1            -> scala-steward/update/typesafe-1.4.1
 * [new branch]          update/woodstox-core-6.2.4       -> scala-steward/update/woodstox-core-6.2.4
 * [new branch]          update/xercesImpl-2.12.1         -> scala-steward/update/xercesImpl-2.12.1
interran@GH3WPL13E:~/apache/daffodil-asf$ git checkout update/jackson-core-2.11.4
Branch 'update/jackson-core-2.11.4' set up to track remote branch 'update/jackson-core-2.11.4' from 'scala-steward'.
Switched to a new branch 'update/jackson-core-2.11.4'
interran@GH3WPL13E:~/apache/daffodil-asf$

[stevedlawrence]

I figured it would be cleaner to just do it on an individual branch basis so it doesn't pollute everything. Maybe steward will delete these branches once they are merged though, so maybe it's not too bad to just fetch everything. I'll update.

[tuxji]

I've downloaded jackson-core-jackson-core-2.11.3.tar.gz, jackson-core-jackson-core-2.11.4.tar.gz, and jackson-core-jackson-core-2.12.2.tar.gz, diff'ed them, found their NOTICE files, and compared their NOTICE file with our bin.NOTICE. I believe we can safely update to 2.11.4 and then 2.12.2 after that since I didn't see any API changes that should affect us. I've incorporated jackson-core's updated NOTICE in our bin.NOTICE and replaced all version numbers in our bin.LICENSE and bin.NOTICE with the literal string <VERSION> to avoid needing to change bin.LICENSE and bin.NOTICE unless dependencies actually change their LICENSE or NOTICE files.

Once I get someone else's +1, I will squash, merge, and move on to the next dependency PR.

[stevedlawrence]

+1 looks good to me!