docs(cf-env): add Spring Boot 4.x test coverage and improve docs#1341
Merged
Conversation
- Add detection tests for SB 4.0 and 4.1 (BOOT-INF/lib, lib/, WEB-INF/lib, MANIFEST.MF) - Update detection criterion to cover both SB 3.x and 4.x - Add version mapping table: SB 3.x → cfenv 3.x, SB 4.x → cfenv 4.x - Clarify cloud profile is activated by the library at runtime, not the buildpack - Add JBP_CONFIG_JAVA_CF_ENV configuration section with enable/disable examples - Document when to disable (manual VCAP_SERVICES handling, unwanted cloud profile, conflicts)
… log - frameworkVersionSuffix now shows '(default: X.Y.Z)' instead of '(X.Y.Z)' making clear this is the manifest default, not necessarily the installed version - Reverts java-cfenv DependencyIdentifier back to 'java-cfenv' (no hack needed) - Removes extra Info log from JavaCfEnvFramework.Supply() Result: single 'Installing Java CF Env (default: 3.5.1)' line; actual installed version visible from libbuildpack install line
There was a problem hiding this comment.
Pull request overview
This PR updates the Java CF Env framework documentation and tests to explicitly cover Spring Boot 4.x detection scenarios, and tweaks framework install logging to clarify that the printed version is the manifest default (not necessarily the resolved/installed version).
Changes:
- Add/shift detection tests to cover Spring Boot 4.1.x across common layouts (BOOT-INF/lib, WEB-INF/lib, lib/, manifest).
- Improve
framework-java-cfenv.mdto document Spring Boot 3.x/4.x support, version mapping, andJBP_CONFIG_JAVA_CF_ENVusage. - Adjust framework install log suffix to display
(default: X.Y.Z)instead of(X.Y.Z).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/java/supply/supply.go | Clarifies install log output by labeling the manifest version as the default. |
| src/java/frameworks/java_cf_env.go | Minor whitespace cleanup in supply logic. |
| src/java/frameworks/java_cf_env_test.go | Updates/extends detection tests to cover Spring Boot 4.1.x layouts and adds a DependencyIdentifier assertion. |
| docs/framework-java-cfenv.md | Documents SB 3.x/4.x support, version mapping, profile behavior, and configuration examples. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Add cf restage to set-env/unset-env examples; buildpack only re-reads JBP_CONFIG_JAVA_CF_ENV during staging - Fix CloudFoundry -> Cloud Foundry, detail -> details - Add trailing newline
The `cloud` Spring profile is activated by CloudProfileApplicationListener, which ships only in the java-cfenv-all module (not java-cfenv-boot or the core module). Correct the framework doc and the migration guide's troubleshooting entry, and show SPRING_PROFILES_INCLUDE (add alongside existing profiles) vs SPRING_PROFILES_ACTIVE (replace) for explicit activation. Refs cloudfoundry#1349.
The main migration steps recommended java-cfenv-boot 3.1.4, which does not carry CloudProfileApplicationListener and so drops the `cloud` profile -- contradicting the guide's own notes. Switch the pom/gradle snippets and checklist to java-cfenv-all, version-matched to the app's Spring Boot major (3.5.1 for 3.x, 4.0.0 for 4.x), and note java-cfenv-boot as the lighter option for apps that do not need the `cloud` profile. Refs cloudfoundry#1349.
Copilot review: '(default: X)' could read as 'the buildpack installs this by default'. Say 'manifest default' — for java-cfenv the manifest default differs from the version actually installed (resolved per Spring Boot major).
…ation Spring Auto-reconfiguration is deprecated and disabled by default; the container docs still claimed it sets the `cloud` profile. java-cfenv (the java-cfenv-all module) is the replacement and activates `cloud` at runtime. Update the five container docs; also mention SPRING_PROFILES_INCLUDE for explicit activation. Refs cloudfoundry#1349.
Revert the cloud-profile reword in the Tomcat/WAR container doc: java-cfenv detects only Spring Boot 3.x/4.x apps, so it does not apply to plain Spring MVC WARs served by the Tomcat container. The four Spring Boot container docs keep the java-cfenv wording.
Add a 'How it works' section (Detect/Supply/Finalize/Runtime) describing the
java_cf_env framework, and document how to limit the automatic behaviour:
JBP_CONFIG_JAVA_CF_ENV '{enabled: false}' disables the whole framework, and —
since the buildpack backs off when the app bundles its own java-cfenv*.jar — an
app can bundle java-cfenv-boot (props, no cloud profile) or java-cfenv core
(neither) to scope it.
Refs cloudfoundry#1349.
…-compat note Mirror the framework doc's control options (JBP_CONFIG_JAVA_CF_ENV disable; bundle java-cfenv-boot/core to scope behaviour) and note that from java-buildpack 5.0.6 the default java-cfenv-all injection restores 4.x parity for the cloud profile and VCAP_SERVICES property mapping (5.0.0-5.0.5 shipped bare core; see cloudfoundry#1349). Refs cloudfoundry#1349.
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.
Summary
This PR adds missing test coverage, improves docs, and fixes a misleading log line. No functional code changes to the cf-env detection or installation logic.
Changes
Tests
Docs (
docs/framework-java-cfenv.md,docs/spring-auto-reconfiguration-migration.md)cloudSpring profile is activated at runtime by java-cfenv'sCloudProfileApplicationListener(which ships in thejava-cfenv-allmodule), not by the buildpack; documentSPRING_PROFILES_INCLUDE=cloud(add) vsSPRING_PROFILES_ACTIVE=cloud(replace) for explicit activationJBP_CONFIG_JAVA_CF_ENVconfiguration section with enable/disable/unset examples and when to disablecontainer-{dist_zip,java_main,spring_boot,spring_boot_cli}.md): correct the stale claim that Spring Auto-reconfiguration sets thecloudprofile — it is deprecated/off by default; java-cfenv is the replacement that activatescloudjava-cfenv-all(version-matched to the app's Spring Boot major) rather than the stalejava-cfenv-boot:3.1.4, since only-allcarries the profile listenerLogging fix (
src/java/supply/supply.go)frameworkVersionSuffixnow shows(manifest default: X.Y.Z)instead of(X.Y.Z), making clear this is the manifest default version — not necessarily what gets installed (relevant for java-cfenv which selects 3.x or 4.x based on detected Spring Boot version)Before:
After:
Please review if complete or must be extended.