Repository navigation
stacks: java development loadout (jdk + maven + gradle + jdtls) - #899
Merged
Merged
Conversation
An opt-in stack, like `aeneas` and `reveng`: no matches_project_if_any, so pom.xml / build.gradle keep selecting the plain `maven` / `gradle` build stacks. Bundles the current-LTS `jdk`, both build tools and the Eclipse JDT language server, with the JAVA_HOME / MAVEN_OPTS the maven and gradle stacks already use. build_cmd smokes every anchor (java, javac, mvn, gradle, jdtls, jdb) so a broken session fails at start. jdb is reached through JAVA_HOME because the jdk package only links eight of its tools into /usr/bin. Only packages already on main. Formatters, linters and the rest are listed in a trailing comment as not-yet-packaged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Warning Review limit reached
This review includes 1 billable file and costs up to $0.25.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 51 minutes for your next included review. View limit details
|
This was referenced Oct 16, 2026
All three Java stacks now name jdk-25 (pkgs#897) rather than the `jdk` meta, so a project's Java doesn't move when `jdk` rolls to the next LTS. The header's `$JAVA_HOME/bin/jdb` is plain `jdb` now that #897/#898 link every JDK tool into /usr/bin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 16, 2026
Merged
Merged
Merged
Merged
Merged
Merged
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Oct 22, 2026
* mvnd: add 1.0.6 (Apache Maven Daemon, embeds Maven 3.9.16) Per-arch upstream tarballs (GraalVM native client + daemon jars + embedded Maven) under /usr/share/mvnd, matched on target arch like packages/jdk. A /usr/bin/mvnd wrapper defaults JAVA_HOME to the packaged jdk (the daemon is a JVM) and pins MVND_HOME. The embedded Maven's bin/mvn stays off PATH; /usr/bin/mvn belongs to `maven`. The embedded Maven version is pinned in build.ncl; build.sh fails closed if the tarball's maven-core jar disagrees, and the tests assert both versions. Standalone tests: --version through a live daemon, and an offline (-o) `validate` of a packaging=pom project, each stopping the daemon afterwards. Refs #899. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * mvnd: share maven's repository, wire daemon storage, declare network needs Review fixes: - The wrapper forwards MAVEN_REPO_LOCAL (maven's wired local repository) as -Dmaven.repo.local, so mvn and mvnd in one session share it. - env_state_wiring MVND_DAEMON_STORAGE -> /state/mvnd: the native client reads it itself, so the daemon registry no longer needs a writable HOME. - needs { dns, internet } as the consumer-facing network dep, matching jbang/curl/go/uv: resolving from Maven Central is mvnd's job. - Tests set the two wired variables instead of -D flags, and check that the daemon used that storage and the build that repository. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
bryan-minimal
marked this pull request as ready for review
October 25, 2026 23:14
mitodrummer
reviewed
Oct 28, 2026
Member
There was a problem hiding this comment.
The stack itself is fine: jdk-25 matches the maven/gradle stacks, JAVA_HOME and MAVEN_OPTS are the same values, and it is opt-in. But the text in it has fallen behind main:
stacks/java/stack.ncl:24-25and:75-86: the "NOT YET PACKAGED" list is out of date. google-java-format, checkstyle, pmd, jbang, kotlin, async-profiler, spotbugs and mvnd are all on main now (packages/<name>; mvnd ismvnd, notmaven-mvnd). The file says to "add each here the day its package lands on main", so either add the ones you want tobuild_packagesor drop the list. As written, line 24 tells readers formatters and linters are "NOT packaged yet".:68-72: the jdb rationale no longer holds.packages/jdk-25/build.shnow links everyusr/lib/jvm/bin/*into/usr/bin, sojdbis on PATH.$JAVA_HOME/bin/jdbstill works, but the comment explaining it is wrong. Calljdb -versiondirectly or fix the comment.- PR body: the table and the "Verified" block describe the
jdkmeta on Temurin 21.0.12.1, but the file pinsjdk-25. The checklist's Tier 0 and Tier 1/2 items have mostly landed. Please refresh it so the PR matches what merges, and re-run thebuild_cmdsmoke on jdk-25.
google-java-format, checkstyle, pmd, spotbugs, async-profiler, mvnd, kotlin and jbang are all packages on main now, so add them to build_packages and drop the "NOT YET PACKAGED" list. Each depends on the `jdk` meta, which is jdk-25, so the closure still holds one JDK. jdk-25 links every usr/lib/jvm/bin/* into /usr/bin, so build_cmd calls `jdb -version` directly and the JAVA_HOME rationale is gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
@mitodrummer thanks. All three points were right. I merged main first (5a17a91; the branch was 199 commits behind), then:
|
mitodrummer
reviewed
Nov 2, 2026
Member
There was a problem hiding this comment.
Points 1 and 2 are fixed in e24a3fc. All eight tools are on main and each depends on the jdk meta, which is jdk-25, so the closure holds one JDK (stacks/java/stack.ncl:53-61). jdb -version is now called directly (:83), and packages/jdk-25/build.sh does link every usr/lib/jvm/bin/* into /usr/bin. The body table matches the pin.
Still open: the build_cmd smoke on jdk-25 with the added tools. The body's "Verified" section says it hasn't been re-run yet. Please post that run.
Member
Author
|
@mitodrummer here is the A scratch project pinned
Key lines: Every tool that names its JVM names the same Temurin 25.0.5. x86_64 was not run. The "Verified" section of the body now has this run. minimal.toml of the scratch project[upstream]
repo = "https://github.com/gominimal/pkgs"
branch = "java-loadout"
locked_commit = "e24a3fc4b164a2e75225b9e325ce2ddd928299bc"
[stack]
use = "java"
# The stack's build_cmd, verbatim from stacks/java/stack.ncl@e24a3fc4.
[tasks.smoke]
bash = "set -x; java -version && javac -version && mvn -v && gradle --version && jdtls --help > /dev/null && echo JDTLS_HELP_OK && jdb -version"
# Version lines for the eight added tools (not in build_cmd).
[tasks.tools]
bash = '''
set -x
uname -m
echo JAVA_HOME=$JAVA_HOME MAVEN_OPTS=$MAVEN_OPTS
google-java-format --version
checkstyle --version
pmd --version
spotbugs -version
asprof --version
mvnd --version
kotlinc -version
jbang --version
'''Full log:
|
mitodrummer
approved these changes
Nov 3, 2026
Member
There was a problem hiding this comment.
The build_cmd smoke on jdk-25 at e24a3fc exits 0. The command matches stacks/java/stack.ncl:83 verbatim, and every tool that reports its JVM names the same Temurin 25.0.5. The body's "Verified" section records it, and minimal build is green on the head. Approving. x86_64 hasn't been smoke-run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
stacks/java/stack.ncl, an opt-in Java development loadout. It follows theaeneas/revengloadout convention: astackwith nomatches_project_if_any, a header comment that shows the workflow, and abuild_cmdthat smoke-tests every anchor tool.jdk-25maven/gradlestacks.jdk-25links everyusr/lib/jvm/bin/*into/usr/bin.maven,gradlejdtls-data/-configurationto a writable cache.google-java-format,checkstyle,pmd,spotbugsasync-profilerasprof,jfrconv.mvnd,kotlin,jbangbase,curlmaven/gradlestacks.Env:
JAVA_HOME=/usr/lib/jvmandMAVEN_OPTS=-Dmaven.repo.local=/state/m2/repository, the values the maven and gradle stacks already use. Gradle needs nothing extra because its package already wiresGRADLE_USER_HOMEthroughenv_state_wiring.Why opt-in: a
pom.xmlorbuild.gradlealready selects the plainmaven/gradlebuild stack, and this stack must not compete with them.Only packages already on main. No new packages in this PR. Every added tool depends on the
jdkmeta, which isjdk-25, so the closure holds one JDK.Verified
Stacks have no
testsfield, so thebuild_cmdsmoke is the test, as inreveng. It isjava -version && javac -version && mvn -v && gradle --version && jdtls --help > /dev/null && jdb -version.2026-11-02, aarch64, at e24a3fc. A scratch project pinned
[upstream]tojava-loadout@e24a3fc4b164a2e75225b9e325ce2ddd928299bcwith[stack] use = "java", and ran two tasks withmin task run(each in its own ephemeral min box, destroyed afterwards; nothing built on the Mac):smokeis thebuild_cmdverbatim, withset -xand anechoafterjdtls --help > /dev/nullso its step shows. Exit 0.toolsprints the version line of each of the eight added tools, plusJAVA_HOME/MAVEN_OPTSfrom the stack'sbuild_env_vars. Exit 0.openjdk version "25.0.5" 2026-10-20 LTS·OpenJDK Runtime Environment Temurin-25.0.5+8 (build 25.0.5+8-LTS)javac 25.0.5Apache Maven 3.10.0·Java version: 25.0.5, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm·arch: "aarch64"Gradle 9.8.2·Launcher JVM: 25.0.5 (Eclipse Adoptium 25.0.5+8-LTS)·Daemon JVM: /usr/lib/jvmjdtls --helpexits 0This is jdb version 25.0 (Java SE version 25.0.5), called from PATHgoogle-java-format: Version 1.37.0Checkstyle version: 14.3.0PMD 7.28.0 (79726f0e…, 2026-09-25T07:52:15Z)·Java version: 25.0.5, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm4.10.5Async-profiler 4.6 built on Jan 1 1970(asprof --version)Apache Maven Daemon (mvnd) 1.0.6 linux-aarch64 native client· embeddedApache Maven 3.9.16·Java version: 25.0.5info: kotlinc-jvm 2.4.21 (JRE 25.0.5+8-LTS)0.143.0JAVA_HOME=/usr/lib/jvm MAVEN_OPTS=-Dmaven.repo.local=/state/m2/repositoryEvery JVM tool that reports its runtime (mvn, gradle, pmd, mvnd, kotlinc) reports the same Temurin 25.0.5 at
/usr/lib/jvm. x86_64 was not run. mvnd embeds Maven 3.9.16 whilemvnis 3.10.0; that is upstream's mvnd 1.0.6 bundling, as the checklist notes.The full logs are in the reply that posted this run.
min task run, on thejdkmeta when it was Temurin 21.0.12.1. Every step passed.Follow-up packaging checklist
The list is ranked by usefulness × ease. Each item is one package PR; tick it when it lands, then add the package to
build_packageshere.Licences were checked against each upstream's LICENSE file. "Easy" means a prebuilt, architecture-independent jar or zip plus a launcher script (the
maven/gradle/jdtlsshape). "Medium" means per-arch prebuilt natives or Maven-Central-only artifacts.Items marked [x] have landed on main, and the packages are in this stack's
build_packages(e24a3fc).Tier 0: fix in an existing package
jdk: link everyusr/lib/jvm/bin/*into/usr/bin. Today only java, javac, jar, jlink, jmod, jpackage, jshell and keytool are linked, sojdb,jcmd,jfr,jstack,jmap,javap,jdeps,javadocandjwebserverare missing from PATH. The same list is in jdk: current LTS (meta over jdk-25); add jdk-25 (Temurin 25) and jdk-21 (Temurin 21) #897'sjdk-25/build.sh. Easy.gradlestack: also matchbuild.gradle.kts/settings.gradle.kts. Today it matches onlybuild.gradle/settings.gradle, so a Kotlin-DSL project (thegradle initdefault) never selects it. Trivial.Tier 1: high value, easy
linux-x86-64/linux-arm64binaries (GraalVM native-image) and an all-deps jar. Easy. Prefer the jar plus a launcher (it needs the--add-exports jdk.compiler/...flags) if we want it built on our JDK; the native binaries are the zero-dependency option.checkstyle-X-all.jaron GitHub releases. Easy.pmd-dist-X-bin.zipon GitHub releases. Easy. ⚠ Licence: PMD's own BSD-style text with a DARPA acknowledgement clause, with Apache-2.0 parts. It is redistributable but has no exact SPDX id, so it needs aLicenseRef-PMD(or a reviewed SPDX choice) for license-lint..javascripts with//DEPS; it is the Java answer touv run. MIT. Linux tar on GitHub releases (shell launcher plus jar). Easy. Caveat: it downloads deps and JDKs at run time, so setJBANG_JDK_VENDOR/JAVA_HOMEso it uses ours.kotlinc). The second JVM language most Java shops touch (Gradle Kotlin DSL, Android). Apache-2.0.kotlin-compiler-X.zipon GitHub releases is pure JVM. Easy. Akotlinloadout could build on this later.linux-x64/linux-arm64tarballs on GitHub releases (a native agent.soplus theasprofbinary). Easy to medium: prebuilt natives, and it should be built from source (C++ plus make) to match our policy.Tier 2: useful, a bit more work
spotbugs-X.tgzon GitHub releases. Easy. Usually run as a build plugin, but the CLI is handy for scanning a jar you didn't build.mvnd). A persistent Maven that is much faster on multi-module builds. Apache-2.0. Per-arch native clients on GitHub releases. Medium: the client is a GraalVM native-image, and the daemon embeds its own Maven version. Note a release can lag Maven by a minor version.kotlinclands. ktlint is MIT (ktlintself-executing jar on GitHub). ktfmt is Apache-2.0 (jar and linux-x86_64 native on GitHub; no arm64 native). Easy.apache-groovy-binary-X.zipfrom the Apache dist. Easy, but lower value now that Gradle defaults to the Kotlin DSL and bundles its own Groovy.quarkus-cli-X.tar.gzon GitHub releases. The Spring Boot CLI is on Maven Central / repo.spring.io. Easy, but framework-specific, so they arguably belong in a framework loadout rather than the base Java one.jdtlsinto a Debug Adapter Protocol server for editor or agent debugging. It has no release jar, so it must be built from source with Maven. Medium. Until thenjdbcovers terminal debugging.Probably separate loadouts (not this one)
scala/scala-cli(Apache-2.0, per-arch natives on GitHub),sbt(Apache-2.0,sbt-X.tgzon GitHub), Coursiercs(Apache-2.0, per-arch natives). Coursier is how the Scala ecosystem installs everything else, which fights a hermetic package set. Suggest ascalaloadout once the JDK side settles.clojure-tools(EPL-1.0). Same shape.native-image): GPL-2.0 with the Classpath exception. A second JDK; a separatejdk-graalpackage, not part of this loadout.Not packages: build plugins or dependencies
These ride the project's own
pom.xml/build.gradleand resolve from Maven Central, so packaging them would be dead weight:rewrite-maven-plugin/ Gradle plugin): core is Apache-2.0.Deliberately excluded
modCLI. Moderne's proprietary distribution. Some recipe modules have also moved to a source-available (non-OSI) licence. Use the Apache-2.0 build plugins.jfr+jcmdin the JDK, plus async-profiler, cover the CLI need../mvnw/./gradlew. Wrappers download a distribution at run time. The packagedmvn/gradleare the hermetic path. The loadout does not block wrappers, but it does not rely on them.Open questions
javasits next to themaven/gradlebuild stacks. Is that clear enough, or should it bejava-dev/jvmto signal "loadout, not build stack"?jdkvs a pinned line. Settled: the stack pinsjdk-25, as themaven/gradlestacks do.user.home. The local reveng loadout found that Java resolvesuser.homefrom the passwd entry (/root) and not from$HOME. Maven's~/.m2/settings.xmland tools that write underuser.homemay hit this in sessions.MAVEN_OPTScovers the Maven repo. Should the stack also setJAVA_TOOL_OPTIONS=-Duser.home=/home? The cost is that every JVM then printsPicked up JAVA_TOOL_OPTIONSto stderr.🤖 Generated with Claude Code