Bump io.zipkin.reporter2:zipkin-reporter-bom from 2.16.4 to 2.17.1

[dependabot]

Bumps io.zipkin.reporter2:zipkin-reporter-bom from 2.16.4 to 2.17.1.

Release notes

Sourced from io.zipkin.reporter2:zipkin-reporter-bom's releases.

Zipkin Reporter 2.17.0

Zipkin Reporter v2.17.0 updates default versions of dependencies so that CVE scanners like trivy pass by default. Details below for the interested.

For example, trivy is now clean.

$ trivy -q --skip-files "**/src/it/*/pom.xml" repo https://github.com/openzipkin/zipkin-reporter-java

In order to do this, and based on user demand, we had to change some default practice in our senders (the transport plug-in for sending spans to a zipkin compatible endpoint). Here is a summary of each and how versions are handled.

• activemq-client - Note that the recently released 6.x version is not compatible with 5.x due to package import change from javax.jms to jakarta.jms. Raise an issue if you need a later client as it will require a copy of the entire module to resolve.
• amqp-client (rabbitmq) - The 4.x version is no longer maintained, so we set a 5.x version and test the old one.
• kafka - the kafka-clients driver has not had any known compatibility problems, so we've left it as-is.
• libthrift (scribe) - libthrift (used for the deprecated scribe transport) has never released a 1.0 version, so occasionally causes revlocks. @​zhfeng noticed this in apache camel, as updating past the 4 year old 0.13 was impossible to work around. Luckily versions after that seem compatible with each other.
• okhttp3 - The 3.x version is no longer maintained, so we set a 4.x version and test the old one. Thanks @​evantorrie for explaining why this is important and @​shakuzen for helping in the discussion.

While not end-user affecting, we have also migrated from JUnit 4 to JUnit 5, thanks to OpenRewrite recipes from @​TeamModerne. Also, we use docker images to test all messaging transports. This ensures compatibility with upstream in transparent ways, and also removes classpath conflicts from java-based messaging transports such as ActiveMQ and Kafka.

Thanks a lot to @​anuraaga for copious support work on this release, as well.

Full Changelog: openzipkin/zipkin-reporter-java@2.16.5...2.17.0

Note: To pass Trivy at the moment, we have to skip old versions used only for compatibility testing. There is a discussion about making this default.

Zipkin Reporter 2.16.5

Zipkin Reporter v2.16.5 updates dependencies and moves the build to work on current LTS JDKs (11, 17 and 21). Runtime Java versions remain the same. For example, the minimum Java version of the core jar remains 1.6.

Full Changelog: openzipkin/zipkin-reporter-java@2.16.4...2.16.5

Changelog

Sourced from io.zipkin.reporter2:zipkin-reporter-bom's changelog.

OpenZipkin Release Process

This repo uses semantic versions. Please keep this in mind when choosing version numbers.

1. Alert others you are releasing

   There should be no commits made to master while the release is in progress (about 10 minutes). Before you start a release, alert others on gitter so that they don't accidentally merge anything. If they do, and the build fails because of that, you'll have to recreate the release tag described below.

2. Push a git tag

   The trigger format is release-MAJOR.MINOR.PATCH, ex git tag release-1.18.1 && git push origin release-1.18.1.

3. Wait for CI

   The release-MAJOR.MINOR.PATCH tag triggers https://github.com/openzipkin/zipkin-reporter-java/blob/master/build-bin/maven/maven_release, which creates commits, MAJOR.MINOR.PATCH tag, and increments the version (maven-release-plugin).

   The MAJOR.MINOR.PATCH tag triggers https://github.com/openzipkin/zipkin-reporter-java/blob/master/build-bin/deploy, which does the following:

   • Publishes jars to https://oss.sonatype.org/content/repositories/releases https://github.com/openzipkin/zipkin-reporter-java/blob/master/build-bin/maven/maven_deploy
     • Later, the same jars synchronize to Maven Central

   Notes:

   • https://search.maven.org/ index will take longer than direct links like https://repo1.maven.org/maven2/io/zipkin

Credentials

The release process uses various credentials. If you notice something failing due to unauthorized, look at the notes in [.github/workflows/deploy.yml] and check the org secrets.

Troubleshooting invalid credentials

If you receive a '401 unauthorized' failure from OSSRH, it is likely SONATYPE_USER or SONATYPE_PASSWORD entries are invalid, or possibly the user associated with them does not have rights to upload.

The least destructive test is to try to publish a snapshot manually. By passing the values CI would use, you can kick off a snapshot from your laptop. This is a good way to validate that your unencrypted credentials are authorized.

Here's an example of a snapshot deploy with specified credentials.

$ export GPG_TTY=$(tty) && GPG_PASSPHRASE=whackamole SONATYPE_USER=adrianmole SONATYPE_PASSWORD=ed6f20bde9123bbb2312b221 build-bin/build-bin/maven/maven_deploy

First release of the year

The license plugin verifies license headers of files include a copyright notice indicating the years a file was affected. This information is taken from git history. There's a once-a-year problem with files that include version numbers (pom.xml).

... (truncated)

Commits

• 692bb3d [maven-release-plugin] prepare release 2.17.1
• a2060be ci: adds action to test javadoc (#230)
• 66060b3 deps: updates to zipkin 2.25.2 (#229)
• 4e886ea build: fixes animal-sniffer phase and runs on all JDKs (#231)
• e635df8 [maven-release-plugin] prepare for next development iteration
• d21c18e [maven-release-plugin] prepare release 2.17.0
• e8f2052 deps: bumps to zipkin 2.25.1 (#227)
• 555bdc4 benchmarks: replace kafka-unit with docker (#226)
• 077737c amqp-client: moves to latest version and tests prior (#225)
• 8e86704 updates integration tests and benchmarks to use log4j (#224)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud