Eclipse P2 Caching Proxy

Why and When to Use the Eclipse P2 Caching Proxy

Commerce Manager builds rely on external Eclipse P2 repositories, including Eclipse Business Intelligence and Reporting Tools (BIRT). Without this cluster-level cache, each new Jenkins Maven build process must download the Eclipse artifacts from the Internet and, if the remote server is having issues, downloads might fail or time out.

The Eclipse P2 caching proxy addresses this by caching Eclipse P2 and BIRT content inside the Kubernetes cluster. After the cache is warm, most repeated requests are served from the local cache.

We recommend enabling this feature in every CloudOps for Kubernetes cluster where you perform Self-Managed Commerce Maven builds. It is not needed in clusters where you do not perform builds. It is not enabled by default, ensuring that you have control to test implementing it in your builds, and can safely revert if needed.

How the Proxy Fits in the Build Flow

When enabled, CloudOps for Kubernetes makes two changes to Jenkins jobs to ensure they use the proxy:

• The build tooling updates the Maven mirror <url> values in settings.xml so P2 repository requests use http://ep-p2-proxy-service.
• The build tooling appends parameter -Declipse.p2.mirrors=false to Jenkins job's MAVEN_OPTS.

When the proxy is in use it can proxy and cache the following:

• Rich Ajax Platform (RAP)
• Eclipse Releases
• Eclipse Updates
• BIRT

The Eclipse P2 proxy is separate from the Nexus Maven repository manager. Nexus remains responsible for Maven artifacts, while the Eclipse P2 proxy handles Eclipse P2 and BIRT repository traffic.

For architecture context, see Build Infrastructure.

Enable the Eclipse P2 Caching Proxy

Set the following Terraform variables in your docker-compose.override.yml:

• TF_VAR_deploy_p2_proxy: "true"
• TF_VAR_use_p2_proxy: "true"

Then apply the configuration by following the standard reconfiguration workflow. For more information, see Update Cluster Configuration.

What to Expect During Builds

• Build logs should include lines similar to Loading repository ... from mirror ... http://ep-p2-proxy-service/...
• The first clean build warms the cache for repositories and artifacts requested by that build
• Later builds in the same cluster typically reduce repeated external Eclipse downloads

Confirm Builds Are Using the Proxy

You can confirm usage in two places:

1. Maven/Tycho output in Jenkins logs (Loading repository ... from mirror)
2. The generated settings.xml in the build agent (http://ep-p2-proxy-service/... for Eclipse P2 and BIRT mirror entries)

For operational validation, including cache-hit checks and persistent volume claim inspection, see Manage Eclipse P2 Proxy.

Changing the Volume and Cache Size

You can tune proxy storage and cache limits based on your build workload.

important

You can only specify a different volume and cache size before deploying and creating the Eclipse P2 Caching Proxy. Changing these while the Eclipse P2 Caching Proxy is deployed is not supported. To adjust these after deploying the Eclipse P2 Caching Proxy, first disable the proxy, then update the values in your docker-compose.override.yml file, then re-enable the proxy.

p2_proxy_pvc_size

The Terraform variable p2_proxy_pvc_size controls the size of the persistent volume claim used by the proxy cache.

In docker-compose.override.yml, set:

• TF_VAR_p2_proxy_pvc_size to the desired value (for example, 5Gi, 10Gi, or 20Gi)

Start with a smaller value if your observed cache footprint is low, then increase only if needed.

Nginx proxy_cache_path max_size

The nginx cache limit is configured in bootstrap/terraform/config/p2-proxy-nginx.conf in the proxy_cache_path directive:

proxy_cache_path /cache levels=1:2
    keys_zone=p2cache:10m
    max_size=2g
    ...

Set max_size below the persistent volume claim size so cache eviction occurs before the volume is full. As a rule of thumb, keep max_size at about 70-85% of the persistent volume claim capacity to leave filesystem headroom.