fix(java-cfenv): ship java-cfenv-all so the cloud profile is applied#1352
Open
stokpop wants to merge 1 commit into
Open
fix(java-cfenv): ship java-cfenv-all so the cloud profile is applied#1352stokpop wants to merge 1 commit into
stokpop wants to merge 1 commit into
Conversation
The buildpack injected the bare `java-cfenv` core module, which has no META-INF/spring.factories and no CloudProfileApplicationListener. As a result the `cloud` Spring profile and automatic VCAP property mapping were silently dropped versus 4.x, which shipped `java-cfenv-all`. Point the java-cfenv 3.5.1 and 4.0.0 dependencies at the java-cfenv-all artifact (Maven Central), with per-version sha256 verified against the published .sha1 -- this also fixes the two entries previously sharing a single mirror object. Update url_to_dependency_map for the java-cfenv-all-* filename. No framework code change is needed: resolution keys on the manifest name/version, and the hyphenated jar name matches the Finalize classpath glob. Add a network-gated artifact test (build tag cfenv_artifact) that downloads each shipped jar, verifies its sha256, and asserts spring.factories registers CloudProfileApplicationListener. Refs cloudfoundry#1349.
rkoster
requested changes
Jul 8, 2026
rkoster
left a comment
rkoster
left a comment
There was a problem hiding this comment.
I would like it better if the existing spring boot test would be extended to actually confirm environment variables are being parsed by the app in: https://github.com/cloudfoundry/java-buildpack/blob/main/src/integration/spring_boot_test.go
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
2 participants
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.
Summary
Since the Go rewrite, the buildpack injects the bare
java-cfenvcore module. 4.x effectively shippedjava-cfenv-all. The core module has noMETA-INF/spring.factories, noEnvironmentPostProcessor, and noCloudProfileApplicationListener, so apps relying on the buildpack's java-cfenv silently lose thecloudSpring profile and automaticVCAP_SERVICES→ Spring property mapping they had under 4.x. The app starts fine, just without that configuration.Fixes #1349.
Changes
manifest.yml: point thejava-cfenv3.5.1 and 4.0.0 dependencies at thejava-cfenv-allartifact, with per-versionsha256/source_sha256. This also fixes the two entries previously sharing one mirror object (identicaluri/sha256, emptysource_sha256).manifest.yml: updateurl_to_dependency_maptojava-cfenv-all-(\d+\.\d+\.\d+).//go:build cfenv_artifact) that downloads each shipped jar, verifies itssha256, and assertsspring.factoriesregistersio.pivotal.cfenv.profile.CloudProfileApplicationListener.No framework code change is needed: resolution keys on the manifest
name/version, and the hyphenatedjava-cfenv-all-<ver>.jarname matches the existing Finalize classpath glob (java-cfenv-*.jar).Verification
java-cfenv-all-3.5.1.jaris byte-identical to the 4.x Ruby-era mirror (java-buildpack.cloudfoundry.org/java-cfenv/java-cfenv-3.5.1.jar), sha256696225e3…736a1— so this restores the exact artifact 4.x shipped. Hashes were verified against Maven Central's published.sha1.go test ./...unchanged (offline; the networked test is tag-excluded).go test -tags cfenv_artifact ./src/java/frameworks/: RED on the previous core manifest (nospring.factories), GREEN after this change for both 3.5.1 and 4.0.0.Note on the artifact source
The
uripoints directly at Maven Central as an interim, so the fix is self-contained and CI-verifiable now. The convention-correct source is the CF mirror (buildpacks.cloudfoundry.org); the mirror pipeline currently mirrors the wrong Mavenartifact_id(java-cfenvcore). A companion buildpacks-ci change (artifact_id: java-cfenv→java-cfenv-all) will re-mirror the aggregate; once it lands,urican move to the CF host — a no-risk swap since the bytes are identical.