fix(jvm): restore Java env build by installing fission-java-core from source#437
Merged
Conversation
… source io.fission:fission-java-core:0.0.2-SNAPSHOT was only ever published to the oss.sonatype.org OSSRH snapshots repository, which has been decommissioned, so the jvm env, its builder and the example function could no longer resolve the dependency and CI failed. - Add install-fission-java-core.sh which builds the artifact from a pinned commit of fission/fission-java-libs and installs it into the local Maven repository under 0.0.1, 0.0.2 and 0.0.2-SNAPSHOT (the SNAPSHOT version keeps pre-existing user functions building against the jvm-builder image working). The script normalizes the library pom's missing XML namespace declarations which strict plugin parsers reject. Duplicated into jvm/builder/ because the builder image is built with that directory as its Docker context. - Reference fission-java-core 0.0.2 (non-SNAPSHOT) from jvm/pom.xml and the example pom, and drop the dead oss.sonatype.org <repositories> blocks. - jvm/tests/test_java_env.sh installs the artifact inside the clean maven build container before packaging the example function. - Upgrade Spring Boot 3.3.2 -> 3.5.14, Java 22 -> 25 LTS (maven 3.9.16-eclipse-temurin-25-alpine / eclipse-temurin:25-jdk-alpine), example spring-boot-starter-web 2.0.1.RELEASE -> 3.5.14 and surefire 2.22.1 -> 3.5.4. - Bump envconfig version to 1.32.0 (runtimeVersion 25) and regenerate environments.json via make update-env-json (it was stale). Verified locally: env + builder images build, the example jar builds exactly as the CI test does, and a container smoke test passes (/v2/specialize 200, invoke returns "Hello World!" on Java 25.0.3 / Spring Boot 3.5.14). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…r Hub image The jvm e2e test relied on the utils.sh default JVM_RUNTIME_IMAGE (fission/jvm-env from Docker Hub, years out of date), so the image loaded into kind by `make jvm-test-images` was never exercised and the freshly built example jar (release 17 bytecode) failed to load on the ancient runtime. Pin JVM_RUNTIME_IMAGE=jvm-env in the test, matching the go/binary/nodejs/python test convention. Also add Collect Fission Dump on failure to the jvm job (same hunk as in #436) so future e2e failures leave pod-level diagnostics. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Member
Author
|
CI is green ✅ — the jvm e2e job now builds the example jar from source-installed fission-java-core and runs it against the locally built Java 25 / Spring Boot 3.5.14 image (pool manager + new deployment both pass). Ready for merge. |
This was referenced Jun 6, 2026
…n from master which supersedes this branch's jvm-job hunk
sanketsudake
added a commit
that referenced
this pull request
Jun 6, 2026
sanketsudake
added a commit
that referenced
this pull request
Jun 6, 2026
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
1 participant
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.
Problem — why Java CI is failing
io.fission:fission-java-core:0.0.2-SNAPSHOTno longer resolves from anywhere:repo1.maven.org/maven2/io/fission/only containsfission-jvm-jersey).Function,Context).So
mvn packagefails for the env image, the builder's user-function builds, and the example function built byjvm/tests/test_java_env.sh(which builds in a clean maven container — fixing only the images would not fix CI).Fix
New
jvm/install-fission-java-core.sh:e97baa8b(immutable tarball), normalizes the 2018-era pom's missing XML namespace declarations (strict plugin parsers reject it), andmvn installsfission-java-coreunder 0.0.1, 0.0.2 and 0.0.2-SNAPSHOT.0.0.2-SNAPSHOT) building against the newjvm-builderimage — Maven falls back to the local artifact when the dead remote is unreachable.jvm/builder/(that image's Docker build context isjvm/builder/; the copy carries a keep-in-sync note).Used in three places: env image build stage, builder image (pre-seeds
/root/.m2), and the CI test script before packaging the example.Repo poms now reference
fission-java-core:0.0.2(non-SNAPSHOT — never checked against remotes once installed locally) and drop the deadoss.sonatype.org<repositories>blocks.Version bumps
maven:3.9.16-eclipse-temurin-25-alpine/eclipse-temurin:25-jdk-alpinespring-boot-starter-web2.0.1.RELEASE → 3.5.14 (provided), surefire 2.22.1 → 3.5.4,maven.compiler.release17envconfig.json:runtimeVersion25,version1.31.3 → 1.32.0 (triggers release on merge)environments.jsonregenerated viamake update-env-json(was stale — still carried jvm 1.31.1)Verification (local)
jvm-envimage builds (make jvm-env-img DOCKER_FLAGS=--load)jvm-builderimage builds; contains maven 3.9.16 + all three artifact versions in/root/.m2docker runcommand the CI test usesPOST /v2/specialize→ 200,GET /→Hello World!Related
Server.java) intentionally not bundled — once this merges, re-running CI on fix classNotFound when buid java function #409 will give it a real signal.🤖 Generated with Claude Code