qqeasonchen opened a new pull request, #5323:
URL: https://github.com/apache/eventmesh/pull/5323
## What
Single PR that closes #5303 — standardizes storage SPI capabilities via a
typed marker pattern, and ships a JUnit 5 TCK every backend must pass.
## Why
The existing `MeshStoragePlugin` interface is rich but backend-specific
behaviors (end-offset query, pull-cursor rewind, deferred POP ACK, lite topic)
are scattered between `MeshStoragePlugin` default methods, the standalone
`LiteTopicCapable` interface, and ad-hoc `instanceof` checks on concrete
classes (e.g. `createTopic`). Callers have to know per-backend which features
are supported, and there's no shared test base that catches an accidental
removal of a capability override.
## What changes
### New (in `eventmesh-storage-api`)
- `StorageCapabilities` — outer interface grouping 7 capability
sub-interfaces
- `tck.MeshStoragePluginTCK` — abstract JUnit 5 test base
- `InMemoryStoragePlugin` (test scope) — fixture implementing all 7
capabilities
- `tck.MeshStoragePluginTCKSelfTest` (test scope) — runs the TCK against the
in-memory fixture
### Modified
- `KafkaMeshStoragePlugin` declares 5 capabilities (universal 3 +
`EndOffsetQuery` + `AlignPullOffset`)
- `RocketMQRemotingStoragePlugin` declares 4 (universal 3 +
`AlignPullOffset`)
- `RocketMQ5RemotingStoragePlugin` declares 5 (universal 3 +
`DeferredPopAck` + `LiteTopic`)
- 3 new `*MeshStoragePluginTCKTest` classes wire the TCK for each backend
- 3 `build.gradle` files add `junit-jupiter` + `useJUnitPlatform`
## Capability matrix
| Capability | Kafka | RocketMQ 4.x | RocketMQ 5.x |
|---------------------------|:-----:|:------------:|:------------:|
| `TopicManagement` | ✅ | ✅ | ✅ |
| `PartitionAssignment` | ✅ | ✅ | ✅ |
| `ExplicitOffsetCommit` | ✅ | ✅ | ✅ |
| `EndOffsetQuery` | ✅ | ❌ | ❌ |
| `AlignPullOffset` | ✅ | ✅ | ❌ |
| `DeferredPopAck` | ❌ | ❌ | ✅ |
| `LiteTopic` | ❌ | ❌ | ✅ |
The 3 universal capabilities are part of the `MeshStoragePlugin` contract
already; declaring them via `StorageCapabilities` is a self-audit so dropping a
method body by accident fails the TCK, not a smoke test. The 4 backend-specific
capabilities are new — they correspond to existing behavior that was previously
undiscoverable.
## Test results
40 tests across 4 modules, 0 failures:
```
eventmesh-storage-api: 10/10 (TCK self-test against
InMemoryStoragePlugin)
eventmesh-storage-kafka: 10/10 (TCK wiring for KafkaMeshStoragePlugin)
eventmesh-storage-rocketmq: 10/10 (TCK wiring for
RocketMQRemotingStoragePlugin)
eventmesh-storage-rocketmq5: 10/10 (TCK wiring for
RocketMQ5RemotingStoragePlugin)
```
## Out of scope (separate issues)
- **ArchUnit rule** asserting every plugin in `eventmesh-storage-*`
implements the 3 universal capabilities — needs the
`eventmesh-architecture-guard` module that #5305 added to develop. This PR
stays on master (`ba267195c`); when this PR merges, a follow-up can carry the
ArchUnit rule over.
- **`LiteTopicCapable` deprecation** — the historical interface is still
around and still used by callers; consolidating it with
`StorageCapabilities.LiteTopic` can be a follow-up.
## How a backend wires in
```java
class KafkaMeshStoragePluginTCKTest extends
MeshStoragePluginTCK<KafkaMeshStoragePlugin> {
@Override protected KafkaMeshStoragePlugin newPlugin() { return new
KafkaMeshStoragePlugin(); }
@Override protected Set<Class<?>> expectedCapabilities() {
return Set.of(TopicManagement.class, PartitionAssignment.class,
ExplicitOffsetCommit.class, EndOffsetQuery.class,
AlignPullOffset.class);
}
}
```
Closes #5303.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
