Aias00 opened a new issue, #7311:
URL: https://github.com/apache/shenyu/issues/7311
## Background
`shenyu-registry-core` contains a single SPI-backed factory, but its POM
directly depends on every registry implementation:
- ZooKeeper;
- etcd;
- Consul;
- Nacos;
- Polaris;
- Eureka;
- Kubernetes.
This reverses the intended SPI dependency direction. Any consumer of
`shenyu-registry-core`—including admin, SDK, Feign SDK, and the registry
starter—receives all registry clients and their transitive dependencies even
when only one implementation is configured.
The desired direction is:
```text
registry-api <- registry-core
^
|
registry-nacos / consul / etcd / ...
```
Related extension migrations: #7305 and #7308.
## Scope
### Core dependency inversion
- Remove all concrete `shenyu-registry-*` implementation dependencies from
`shenyu-registry-core`.
- Keep only the registry API, ShenYu SPI support, and factory/cache behavior
needed to locate an implementation already present on the classpath.
- Preserve existing SPI resource names and registration keys.
- Produce a clear error when a configured implementation is not present
instead of failing with an opaque null/class-loading error.
### Consumer and starter model
- Introduce explicit dependency/starter choices for each supported registry
implementation, or document direct implementation dependencies.
- Preserve `shenyu-spring-boot-starter-registry` compatibility for a
documented transition window. If it remains an all-in-one starter temporarily,
move aggregate dependencies into that starter rather than back into core.
- Update admin, SDK core, SDK Feign, examples, and integration tests to
declare only the implementation(s) they actually exercise.
- Ensure plugin-store extensions can provide a registry SPI implementation
without modifying `registry-core`.
- Document how users select one or multiple registry implementations.
### Dependency and release hygiene
- Add dependency-tree checks proving `shenyu-registry-core` does not pull
ZooKeeper, etcd, Consul, Nacos, Polaris, Eureka, or Kubernetes clients.
- Update LICENSE/NOTICE and distribution dependency inventories after the
transitive graph changes.
- Add migration and rollback notes for users relying on the old implicit
all-implementation classpath.
## Verification
- Unit-test factory behavior with no implementation, one implementation,
multiple implementations, reinitialization, and missing/unknown register types.
- Run SPI discovery tests for every in-repository implementation.
- Run targeted admin, SDK, and starter tests.
- Run representative instance registration/discovery integration tests.
- Verify Consul/Polaris external implementations remain discoverable through
the same API.
- Run full build, Checkstyle, RAT, and distribution packaging checks.
## Acceptance Criteria
- [ ] `shenyu-registry-core` has no concrete registry implementation
dependency.
- [ ] Core contains only API/SPI/factory responsibilities.
- [ ] Each runtime consumer explicitly selects its registry implementation.
- [ ] Existing starter users have a documented non-breaking transition path.
- [ ] Missing implementations fail with a clear actionable error.
- [ ] Per-implementation SPI and integration tests pass.
- [ ] Dependency-tree assertions prevent future implementation aggregation
in core.
- [ ] LICENSE/NOTICE and release dependency inventories are updated.
--
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]
