Bump the dependencies group with 2 updates

[dependabot]

Bumps the dependencies group with 2 updates: io.jstach.rainbowgum:rainbowgum-slf4j and org.junit.jupiter:junit-jupiter-engine.

Updates io.jstach.rainbowgum:rainbowgum-slf4j from 0.8.2 to 0.10.0

Release notes

Sourced from io.jstach.rainbowgum:rainbowgum-slf4j's releases.

v0.10.0

Rainbow Gum 0.10.0

SUPER DUPER STERIODS AI ENHANCED 💉 RELEASE.

Rainbow Gum is now in Spring Boot camp and we have been juicing! Boot 3 and Boot 4 support is now included!

In all seriousness I did not "vibe" code this release but it was greatly enhanced using Claude and Codex to close the gap on Spring Boot support.

Speaking of which we have a new logo that I created without even using any AI (and it probably shows)! :

https://github.com/jstachio/rainbowgum/blob/main/etc/logo/rainbowgum-logo.svg

The below was written by an AI agent so you know its boring as crap:

Spring Boot: Boot 3 and Boot 4 support are now separate, independently-versioned modules, and the Boot 4 module in particular understands a lot more of Spring Boot's own logging properties out of the box - Boot 3 has since been brought up to the same level. Alongside that, the default appender configuration changed to favor virtual threads and buffer reuse, which shows up as a real throughput win in our own benchmarks (more below).

Spring Boot: split modules, real property support

Rainbow Gum's Spring Boot integration is no longer one module trying to straddle two incompatible major versions. It's now:

• io.jstach.rainbowgum:rainbowgum-spring-boot4 / rainbowgum-spring-boot4-starter - for Spring Boot 4 / Spring Framework 7 (recommended for new projects).
• io.jstach.rainbowgum:rainbowgum-spring-boot3 / rainbowgum-spring-boot3-starter - for Spring Boot 3.

Each is its own artifact with its own release cadence, so a Spring Boot major-version bump on their end doesn't force one on ours, or vice versa.

More importantly, both modules now natively understand a real chunk of Spring Boot's documented logging properties - no custom LoggingSystem boilerplate or workaround classes required in your app:

• logging.level.root / logging.level.<logger>, logging.group.*, debug/trace
• logging.file.name and logging.file.path (directory-only fallback, Spring's own <path>/spring.log convention)
• logging.include-application-name / logging.include-application-group
• logging.pattern.console / .file / .level / .dateformat, logging.exception-conversion-word
• spring.output.ansi.enabled (NEVER/ALWAYS/DETECT)
• logging.charset.console / logging.charset.file - encoders can now be configured with an arbitrary charset, not just UTF-8 (see below)
• logging.structured.format.console / .file - ecs, gelf, and logstash, independently configurable per output, bridging to the new JSON encoders below

... (truncated)

Commits

• 166bb96 Release v0.10.0
• 7da2631 Bump org.codehaus.plexus:plexus-archiver from 4.10.1 to 4.14.0
• dcf888c Fix wrong property keys in the plural-keys example, note appenders alias
• 57b8880 Document the implicit default properties config as a snippet
• ebdb88e Bring Spring Boot 3 property support to parity with Boot 4
• 827a567 Note commons-logging (jcl) as a candidate for its own native implementation
• 133eb8d Document that Spring Boot 4 / Spring Framework 7 dropped spring-jcl
• 6c08ceb Support Spring Boot's logging.charset.console/file properties
• f3d0bff Add LogEncoder.of(LogFormatter, ContentType) static factory
• 5fdbcb7 Make StandardContentType.TEXT_PLAIN report UTF-8 as its charset
• Additional commits viewable in compare view

Updates org.junit.jupiter:junit-jupiter-engine from 6.1.2 to 6.1.3

Release notes

Sourced from org.junit.jupiter:junit-jupiter-engine's releases.

JUnit 6.1.3 = Platform 6.1.3 + Jupiter 6.1.3 + Vintage 6.1.3

See Release Notes.

Full Changelog: junit-team/junit-framework@r6.1.2...r6.1.3

Commits

• f59f60d Release 6.1.3
• cd8ec92 Finalize 6.1.3 release notes
• c8729f2 Restore compatibility with GraalVM 25 (#5901)
• ddc9e74 Update graalvm/setup-graalvm action to v1.6.4 (#5959)
• fe2c52a Update plugin org.graalvm.buildtools.native to v1.1.7 (#5923)
• 62afc02 Delay GraalVM plugin updates for 3 days
• 0cc2902 Skip graalVmTest task if GraalVM env vars are not set
• f6bbfc5 Move GraalVM tests to separate test task (#5903)
• e87e052 Update plugin org.graalvm.buildtools.native to v1.1.6 (#5899)
• 1cd56df Update plugin org.graalvm.buildtools.native to v1.1.5 (#5880)
• 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.