Spring Kit CLI dependency fails to download during Java Buildpack customization

Products

• VMware Tanzu Application Service

Issue/Introduction

When packaging a custom offline Java Buildpack, the process may fail while attempting to download the spring-kit-cli dependency. Although the public repository metadata (index.yml) correctly lists the required version (e.g., 0.5.0), the binary itself is missing from the public GCS/S3 repository, resulting in "404 Not Found" or download errors.

Cause

The spring-kit-cli is a commercial dependency and is not published for direct public download. Only the metadata is exposed publicly to allow the buildpack to perform version verification.

To support customers who perform internal repackaging, Broadcom utilizes a hybrid distribution model. The "Online" Java Buildpack available on the Broadcom Support portal is pre-bundled with these commercial libraries in its internal cache. This differs from standard Open Source Software (OSS) dependencies, which the buildpack typically fetches from the internet only when needed.

Resolution

Do not attempt to retrieve the spring-kit-cli binary from public repositories or host it manually in an external bucket. Instead, leverage the pre-bundled "hybrid" distribution.

Recommended Workflow for Repackaging

1. Use the Online Buildpack as a Base: Download the standard "Java Buildpack" (the "Online" version) from the Broadcom download portal.
2. Preserve the Internal Cache: This buildpack contains commercial components pre-cached in the resources/cache directory.
   • Important: During your organization-specific customization or repackaging, do not remove the existing cached files.
   • Standard optimization scripts or repackaging workflows that strip the resources/cache directory to reduce buildpack size will remove these commercial dependencies. This causes the buildpack to fail during execution because it will attempt (and fail) to download the missing components from the public internet.
3. Package Your Offline Bundle: Proceed with your repackaging process while keeping the original cache intact. Since the dependencies are already present internally, the buildpack will function correctly in an offline environment without needing to reach the public GCS/S3 bucket.