royteeuwen opened a new issue, #531:
URL: https://github.com/apache/maven-build-cache-extension/issues/531
## Description
The Maven Build Cache Extension currently limits only the local cache.
Remote cache entries and cache reports can accumulate indefinitely in shared
repositories, creating unnecessary storage growth and making repository
maintenance difficult.
This issue proposes opt-in remote retention with configurable strategy
providers.
## Configuration
Remote retention is disabled by default:
```xml
<configuration>
<remote enabled="true"
saveToRemote="true"
cleanupEnabled="true"
retentionStrategy="nexus">
<url>https://nexus.example/repository/build-cache/</url>
<maxBuildsCached>5</maxBuildsCached>
<cleanupGracePeriodSeconds>300</cleanupGracePeriodSeconds>
</remote>
</configuration>
```
Supported built-in strategies:
- `nexus`
- `directory-listing`
- `unsupported`
JVM overrides:
```text
-Dmaven.build.cache.maxRemoteBuildsCached=5
-Dmaven.build.cache.remote.cleanup.enabled=true
-Dmaven.build.cache.remote.cleanup.gracePeriodSeconds=300
-Dmaven.build.cache.remote.retention.strategy=nexus
```
If `retentionStrategy` is omitted, the extension retains URL-based
auto-detection for backward compatibility.
## Behavior
For each cache namespace:
```text
<cache-version>/<groupId>/<artifactId>/
```
the selected strategy:
- Retains the newest configured number of cache entries.
- Orders cache entries using `buildinfo.xml` timestamps.
- Uses remote asset timestamps for grace-period protection.
- Does not delete newly uploaded assets during the configured grace period.
- Revalidates remote asset identity and timestamp before deletion.
- Treats already-deleted assets as a successful outcome.
- Cleans stale `build-cache-report.xml` assets separately.
- Preserves namespace isolation.
- Uses best-effort cleanup by default.
- Honors the existing `failFast` behavior.
Remote cleanup has no distributed lock. Concurrent builders may temporarily
retain more entries than configured, but the grace period and pre-delete
revalidation reduce the risk of deleting another builder’s newly uploaded cache.
## Strategy SPI
Retention uses public Maven-native Plexus/Sisu extension points:
```java
public interface RemoteCacheRetentionStrategyProvider {
String name();
boolean supports(String url);
RemoteCacheRetentionStrategy create(
String url,
RemoteCacheHttpClient httpClient,
CacheConfig config,
XmlService xmlService);
}
```
The core extension currently provides:
- `NexusRawRetentionStrategyProvider`
- `DirectoryListingRetentionStrategyProvider`
- `UnsupportedRemoteRetentionStrategyProvider`
Future repository-specific implementations can be packaged separately and
discovered through Plexus/Sisu.
## Nexus Raw Strategy
The Nexus strategy uses the documented Assets API:
```text
GET /service/rest/v1/assets?repository=<repository>
DELETE /service/rest/v1/assets/{assetId}
```
It:
- Handles pagination.
- Normalizes Nexus asset paths.
- Filters assets locally to the exact cache namespace.
- Uses asset IDs for deletion.
- Uses `lastModified` or `blobCreated` for age checks.
- Revalidates asset ID and timestamp before deletion.
- Cleans cache artifacts and build reports.
The configured Maven server must have permission to read and delete assets
from the Nexus hosted repository.
Nexus Raw paths are virtual asset paths rather than real directories. The
extension deletes assets, but cannot delete empty virtual folders independently.
## Generic HTTP/WebDAV Strategy
The generic strategy uses authenticated directory listings and HTTP DELETE
requests.
It is supported only when the remote server provides:
- Stable directory listings.
- Readable cache files.
- File deletion.
- Directory/collection deletion where applicable.
Generic directory listings generally do not expose reliable per-entry
timestamps. Therefore:
- Cache-entry ordering falls back to `buildinfo.xml` timestamps.
- Report retention is unsupported unless reliable remote metadata is
available.
- Unsupported behavior is reported safely rather than guessed.
## Compatibility
- Remote retention is disabled by default.
- Existing local retention behavior is unchanged.
- Existing remote cache entries remain readable.
- Existing remote GET/PUT behavior is preserved.
- Existing XML and JVM property names remain unchanged.
- New configuration properties are additive.
- Compatibility-safe default methods are used for newly added public API
methods where applicable.
## Open Questions
1. Should Nexus-specific retention remain bundled in the core extension or
move to a separate artifact?
2. Should report retention have a separate limit from cache-entry retention?
3. Should future versions add an optional distributed locking provider?
4. Should the public SPI be stabilized in a separate API module before
release?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
