Skip to content

feat: Honor compiler release for Groovy bytecode - #389

Merged
keeganwitt merged 2 commits into
masterfrom
feat/honor-compiler-release
Jun 27, 2026
Merged

feat: Honor compiler release for Groovy bytecode#389
keeganwitt merged 2 commits into
masterfrom
feat/honor-compiler-release

Conversation

@keeganwitt

Copy link
Copy Markdown
Member

Honor maven.compiler.release when deriving Groovy bytecode target configuration.

When targetBytecode is not configured directly, compile and stub generation now prefer maven.compiler.release, then fall back to maven.compiler.target, and finally the existing 1.8 default. This keeps Groovy classfile output aligned with Maven Compiler Plugin release-based Java builds without treating GroovyDoc as a bytecode-producing path.

Version Bump

Bump the plugin snapshot version to 5.1.0-SNAPSHOT for this behavior change.

Fixes #387

keeganwitt and others added 2 commits June 25, 2026 01:47
Use maven.compiler.release to infer the Groovy target bytecode when targetBytecode is not configured directly. Fall back to maven.compiler.target and then the existing 1.8 default so Groovy classfiles match the Java compiler configuration.

Co-Authored-By: Codex <noreply@openai.com>
@keeganwitt
keeganwitt force-pushed the feat/honor-compiler-release branch from a6b1fe0 to 3d29b11 Compare June 25, 2026 05:48
@keeganwitt
keeganwitt marked this pull request as ready for review June 25, 2026 05:49
@keeganwitt
keeganwitt merged commit 3991ff8 into master Jun 27, 2026
5 checks passed
@keeganwitt
keeganwitt deleted the feat/honor-compiler-release branch June 27, 2026 15:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

maven.compiler.release property ignored; fallback to bytecode 1.8 causes build failure with Groovy 5+

2 participants