Adjust docs and some frameworks for the upcoming GA 5.1.0 release

[kiril-keranov]

---

Update framework docs to reflect Go buildpack configuration mechanism
Address to-do points from GA release issue

Summary

The Go buildpack no longer uses config/*.yml files for framework configuration — that was a Ruby buildpack pattern. This PR updates all framework and JRE documentation to reflect the actual configuration mechanism: JBP_CONFIG_<COMPONENT> environment variables with inline YAML.

Changes

README.md — Configuration and Extension section

• Rewrote the opening paragraph to accurately describe JBP_CONFIG_<COMPONENT> env vars with inline YAML instead of the old "env var matching the config file minus .yml" Ruby description
• Added a callout that config/*.yml file-based configuration is not used by this buildpack
• Removed the stale [config/ directory]: config link definition pointing to a non-existent directory
• Addressing some todo points from v5.1.0 GA release plan #1423
• Adjusting sealights and your-kit-profiler frameworks as per the docs

Framework docs

Frameworks with JBP_CONFIG_* support — configuration section rewritten to document the env var, supported fields, defaults, and usage examples.

What was removed from all affected docs

• Prose references to config/<framework>.yml as the configuration mechanism
• repository_root and version table rows (no longer user-configurable; versions are pinned in manifest.yml)
• Broken reference-style link definitions pointing to ../config/*.yml files that do not exist
• Stale links to extending-repositories.md#version-syntax-and-ordering and [repositories] where they were only relevant to the old yml-file pattern

[Copilot]

🟡 Changes recommended

Several pages still advertise ignored or unimplemented settings, and one updated relative link is broken.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates GA messaging and replaces obsolete Ruby-style configuration guidance with Go buildpack environment-variable documentation.

Changes:

• Declares v5.1.0 the first GA Go-based release.
• Documents supported JBP_CONFIG_* settings and examples.
• Removes obsolete configuration-file and repository references.

File summaries

File	Description
README.md	Updates configuration and GA guidance.
RUBY_VS_GO_BUILDPACK_COMPARISON.md	Adds GA status.
adoption-migration-details.md	Updates migration wording and links.
docs/framework-app_dynamics_agent.md	Removes obsolete options.
docs/framework-aspectj_weaver_agent.md	Documents environment configuration.
docs/framework-client_certificate_mapper.md	Documents enablement configuration.
docs/framework-container_customizer.md	Clarifies manifest-managed versioning.
docs/framework-container_security_provider.md	Documents manager settings.
docs/framework-contrast_security_agent.md	Clarifies manifest-managed versioning.
docs/framework-debug.md	Documents debug environment variables.
docs/framework-elastic_apm_agent.md	Clarifies service-based configuration.
docs/framework-google_stackdriver_profiler.md	Documents application metadata overrides.
docs/framework-introscope_agent.md	Clarifies service-based configuration.
docs/framework-jacoco_agent.md	Clarifies service-based configuration.
docs/framework-java_memory_assistant.md	Updates configuration references.
docs/framework-java_opts.md	Replaces file-based configuration example.
docs/framework-jmx.md	Documents JMX environment variables.
docs/framework-jprofiler_profiler.md	Documents profiler settings.
docs/framework-jrebel_agent.md	Documents enablement configuration.
docs/framework-luna_security_provider.md	Documents provider settings.
docs/framework-maria_db_jdbc.md	Clarifies manifest-managed versioning.
docs/framework-metric_writer.md	Documents enablement configuration.
docs/framework-new_relic_agent.md	Revises agent and extension configuration.
docs/framework-postgresql_jdbc.md	Clarifies manifest-managed versioning.
docs/framework-protect_app_security_provider.md	Removes obsolete repository options.
docs/framework-riverbed_appinternals_agent.md	Revises artifact configuration guidance.
docs/framework-sealights_agent.md	Documents supported agent settings.
docs/framework-sky_walking_agent.md	Documents application-name configuration.
docs/framework-spring_auto_reconfiguration.md	Documents enablement configuration.
docs/framework-your_kit_profiler.md	Documents profiler settings.

Review details

• Files reviewed: 30/30 changed files
• Comments generated: 8
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[stokpop]

docs/framework-container_security_provider.md: The TrustManager description says it "reads the contents of /etc/ssl/certs/ca-certificates.crt" but that's only the default — java-buildpack-security-provider's CloudFoundryContainerTrustManagerFactory overrides this path via the CF_CA_CERTS env var if set. Separately, Diego's executor also injects CF_SYSTEM_CERT_PATH (pointing at /etc/cf-system-certificates) for Trusted System Certificates, independent of this framework/jar, and those certs are additionally merged into /etc/ssl/certs — so operator-deployed trusted certs end up picked up by this TrustManager's default path too. Suggest adding a note along these lines:

The location read by the `TrustManager` defaults to `/etc/ssl/certs/ca-certificates.crt` but can be overridden with the `CF_CA_CERTS` environment variable. Note this is distinct from — but complementary to — Cloud Foundry's [Trusted System Certificates](https://docs.cloudfoundry.org/devguide/deploy-apps/trusted-system-certificates.html) feature (`CF_SYSTEM_CERT_PATH`, `/etc/cf-system-certificates`), whose certificates are also merged into `/etc/ssl/certs` and therefore picked up automatically.

Confirmed via java-buildpack-security-provider's CloudFoundryContainerTrustManagerFactory.java and diego-release's executor/depot/containerstore/storenode.go.

[kiril-keranov]

docs/framework-container_security_provider.md: The TrustManager description says it "reads the contents of /etc/ssl/certs/ca-certificates.crt" but that's only the default — java-buildpack-security-provider's CloudFoundryContainerTrustManagerFactory overrides this path via the CF_CA_CERTS env var if set. Separately, Diego's executor also injects CF_SYSTEM_CERT_PATH (pointing at /etc/cf-system-certificates) for Trusted System Certificates, independent of this framework/jar, and those certs are additionally merged into /etc/ssl/certs — so operator-deployed trusted certs end up picked up by this TrustManager's default path too. Suggest adding a note along these lines:

The location read by the `TrustManager` defaults to `/etc/ssl/certs/ca-certificates.crt` but can be overridden with the `CF_CA_CERTS` environment variable. Note this is distinct from — but complementary to — Cloud Foundry's [Trusted System Certificates](https://docs.cloudfoundry.org/devguide/deploy-apps/trusted-system-certificates.html) feature (`CF_SYSTEM_CERT_PATH`, `/etc/cf-system-certificates`), whose certificates are also merged into `/etc/ssl/certs` and therefore picked up automatically.

Confirmed via java-buildpack-security-provider's CloudFoundryContainerTrustManagerFactory.java and diego-release's executor/depot/containerstore/storenode.go.

Adjusted as suggested

[stokpop]

Thanks!