aws#605)

* chore: update version

* chore: updating release note and changelog

…s#615)

This package previously had no tests and no JUnit dependency. Add
JUnit Jupiter, the surefire plugin, and an initial test class that
exercises the full plugin resolution path end-to-end: a log4j2.xml
on the test classpath, a real LogManager-issued logger, and stdout
capture (LambdaAppender writes through LambdaRuntime.getLogger() to
System.out).

The TEXT test routes the root logger through LambdaTextFormat with a
deterministic PatternLayout and asserts each level appears. The JSON
test adds a second LambdaAppender with format="JSON" backed by
JsonTemplateLayout + LambdaLayout.json, attached via additivity=false
to a "json-test" logger, and asserts the messages show up
JSON-encoded.

Add log4j-layout-template-json at test scope so the JSON path can
resolve at test time. Users are still expected to bring their own
copy at runtime (peer-dependency model, like PatternLayout); the
published artifact's dependency surface is unchanged.

The tests succeed on Java 8 and fail on Java 25, because annotation
processors are not run by default on Java 25, Log4j2Plugins.dat is
not generated for our plugins, and both tests surface the resulting
CLASS_NOT_FOUND from the log4j status logger.

Release 1.6.3 was built on a JDK that does not run annotation processors
by default, which silently dropped the Log4j2 plugin descriptor
(META-INF/.../Log4j2Plugins.dat) for LambdaAppender, LambdaTextFormat,
and LambdaJsonFormat. The published artifact was broken at runtime:
log4j could not resolve <Lambda>, <LambdaTextFormat>, or
<LambdaJsonFormat> elements in user log4j2.xml configurations.

Configure maven-toolchains-plugin to require a JDK 8 toolchain so javac
comes from a JDK that runs annotation processors by default, regardless
of which JVM Maven is invoked under. The version range [1.8,9) matches
both "1.8" and "8".

The existing GitHub Actions workflow at
.github/workflows/aws-lambda-java-log4j2.yml uses actions/setup-java@v5
with java-version: 8 and distribution: corretto. setup-java@v5
auto-generates a ~/.m2/toolchains.xml entry with <version>8</version>,
which the [1.8,9) range matches, so no workflow changes are required.

When no matching JDK 8 toolchain is available, the build now fails fast
at the validate phase with a clear "Cannot find matching toolchain
definitions" error instead of silently producing an artifact missing its
plugin descriptor.

Co-authored-by: Davide Melfi <[email protected]>

Added note regarding v1.6.3.