fix(java-cfenv): add the mirrored java-cfenv-all jar to the classpath

[stokpop]

Summary

The java-cfenv framework ships the correct artifact again — main now mirrors java-cfenv-all (the aggregate module that carries CloudProfileApplicationListener and the property post-processors), via the buildpacks-ci pipeline change and the releng bot PRs #1355 / #1356.

But that alone does not activate the cloud profile: the mirror installs the jar as java-cfenv_<version>_<stack>_<sha>.jar (underscores), while Finalize globbed java-cfenv-*.jar (hyphen). The two do not match, so the jar landed in deps/…/java_cf_env/ but was never added to the profile.d CLASSPATH — at runtime the cloud profile still would not activate. Existing Finalize tests passed only because they used hyphenated fixtures, not the real mirror name.

Completes the runtime half of #1349 (the manifest/artifact half is already on main).

Changes

• java_cf_env.go — Finalize now globs java-cfenv*.jar, matching both the Maven name (java-cfenv-all-<ver>.jar) and the CF mirror name (java-cfenv_<ver>_<stack>_<sha>.jar). This mirrors the pattern hasJavaCfEnv already uses.
• java_cf_env_test.go — add a Finalize test using the real underscore mirror filename (fails before the fix).
• java_cf_env_artifact_test.go — network-gated test (//go:build cfenv_artifact) that downloads each shipped jar, verifies its sha256, and asserts spring.factories registers io.pivotal.cfenv.profile.CloudProfileApplicationListener. Guards against ever shipping the bare core module again.

No manifest change — that landed via #1355 / #1356.

Verification

• go test ./... — green (the artifact test is tag-excluded / offline).
• go test ./src/java/frameworks/ — the new Finalize test is RED before the glob fix, GREEN after.
• go test -tags cfenv_artifact ./src/java/frameworks/ — GREEN against the current mirror -all jars (3.5.1, 4.0.0); would fail on the bare core module.

[rkoster]

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

[ramonskie]

within #1355 and #1356

the package naming has not been changed to prevent confusion.
so we are still using java-cfenv

[stokpop]

Note — related latent risk (not fixed here, no shipping dep):

I audited the other install-dir jar globs for the same hyphen-vs-mirror-name mismatch. All currently-shipped deps are fine (verified with filepath.Match): the flexible <name>*.jar globs match both forms, and the hyphen globs (postgresql-*, metric-writer-*, container-security-provider-*, auto-reconfiguration-*, java-memory-assistant-*) all match their real installed filenames.

One dormant case: container_customizer.go globs container-customizer-*.jar — the same fragile shape as java-cfenv (full name + trailing hyphen). It is not in manifest.yml today, so nothing ships it. But if container-customizer is ever added as a buildpacks.cloudfoundry.org mirror dependency (installed as container-customizer_<ver>_<stack>_<sha>.jar), that glob would silently miss it exactly like this bug.

Suggested convention going forward: install-dir globs should use <name>*.ext, not <name>-*.ext.

[Copilot]

Pull request overview

This PR restores runtime activation of the Spring cloud profile via buildpack-injected java-cfenv-all by ensuring the mirrored (underscore-named) JAR is actually added to the profile.d CLASSPATH, and adds regression tests to prevent shipping the wrong artifact again.

Changes:

• Update Finalize to glob java-cfenv*.jar so both Maven (java-cfenv-all-<ver>.jar) and mirror (java-cfenv_<ver>_<stack>_<sha>.jar) names are picked up.
• Add a Finalize unit test covering the real underscore mirror filename.
• Add a network-gated artifact verification test (build tag cfenv_artifact) that validates manifest SHA256 and presence/registration of CloudProfileApplicationListener via META-INF/spring.factories.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/java/frameworks/java_cf_env.go	Adjusts Finalize JAR glob to include mirrored underscore-named artifacts so they get added to runtime CLASSPATH.
src/java/frameworks/java_cf_env_test.go	Adds a regression test proving Finalize handles the underscore mirror JAR name.
src/java/frameworks/java_cf_env_artifact_test.go	Introduces an opt-in (tagged) network test to validate shipped java-cfenv artifacts are the correct “all” jars and match manifest SHA256.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[stokpop]

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

Agreed a runtime assertion would be stronger. I thought about this, but the current spring boot fixture is not a real spring boot app. its a plain HttpServer in a fake spring-boot-*.jar. There is no VCAP_SERVICES parsing or activation of cloud profile. And a way to check if it is done. Happy to add in follow-up. There is the artifact check that guards regression in meantime.

If we want a full spring boot app to test with: add 10-20MB jar in repo (not a good idea), build one on the fly (needs more build tools like maven on ci), fetch a test app somewhere (github published artifact?). WDYT? Worth it, other solution?

[rkoster]

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

Agreed a runtime assertion would be stronger. I thought about this, but the current spring boot fixture is not a real spring boot app. its a plain HttpServer in a fake spring-boot-*.jar. There is no VCAP_SERVICES parsing or activation of cloud profile. And a way to check if it is done. Happy to add in follow-up. There is the artifact check that guards regression in meantime.

If we want a full spring boot app to test with: add 10-20MB jar in repo (not a good idea), build one on the fly (needs more build tools like maven on ci), fetch a test app somewhere (github published artifact?). WDYT? Worth it, other solution?

Thanks for the context, let's stay with the artifact check to guard against the regression.