qqeasonchen opened a new pull request, #5322:
URL: https://github.com/apache/eventmesh/pull/5322
## Summary
Completes the A+B setup for `:eventmesh-architecture-guard` (issue #5305)
and, in the process, fixes two defects that made the rules useless since they
landed in #5298 / #5297.
## The headline problem: WARN mode was silent
The module has **no SLF4J binding** on its test runtime classpath, so
`LoggerFactory` returns the NOP logger and every
```java
LOG.warn("...violations:/n{}", r.getFailureReport());
```
call was **discarded**. Verified empirically: the `architectureCheck`
test-results XML has an empty `<system-out>` block even though all 10 `*_warn`
methods ran and passed.
**The 10 rules had never actually been read by anyone. CI green was not
evidence of anything.**
## What FAIL mode revealed
Switching to `rule.check(classes)` immediately reported **192 violations
across 4 rules**. Two defects accounted for all of them.
### Defect 1 — wrong package name in 3 exclusion clauses (167 violations)
`ArchitectureRules.java` excluded
```java
"org.apache.eventmesh.protocol.plugin.meshmessage.."
```
but the real package is `org.apache.eventmesh.protocol.meshmessage` — there
is no `.plugin` segment. Confirmed with `git cat-file -p ... | grep ^package`.
The exclusion never matched, so all 7 protocol adapters were judged as ordinary
offenders:
| Rule | Violations |
|---|---|
| `ruleHttpProtocolHidden` | 107 |
| `ruleTcpProtocolHidden` | 46 |
| `ruleGrpcProtocolHidden` | 14 |
Fixed by correcting the three package strings. No rule semantics change.
### Defect 2 — `ruleRuntimeTcpInternalNoReverse` was unsatisfiable (25
violations)
```java
.that().resideInAPackage("...tcp.internal..")
.should().dependOnClassesThat().resideInAPackage("org.apache.eventmesh.runtime.tcp..")
```
The trailing `..` on the should() side covers `runtime.tcp.internal`
**itself**, so the rule forbids internal classes from depending on their own
package. Every reported "violation" was of this shape:
```
NettyTcpPushChannel.deliver -> TcpAckRegistry.register internal
-> public (normal)
TcpPushChannel.deliver -> TcpFrameCodec.encodePush internal
-> internal
TcpPushChannel.deliver -> TcpPushChannel$TcpSessionSink.write its own
nested type
TcpRequest$Kind.values -> TcpRequest$Kind.clone itself
```
**Rule deleted.** Narrowing the `..` would not rescue it either: internal
implementations depending on the public types they implement is ordinary
layering. The boundary that matters is already covered by
`ruleRuntimeTcpInternalHidden`, which keeps everything outside `runtime.tcp`
away from `runtime.tcp.internal`.
**Rules in force: 10 → 9. All 9 pass in FAIL mode.**
## A+B
**B — local (unchanged mechanism, now actually effective):**
```bash
./gradlew :eventmesh-architecture-guard:architectureCheck
```
Fails in seconds, so a developer sees a violation before pushing.
**A — CI (new):** `.github/workflows/architecture-guard.yml` runs the same
task on pushes/PRs touching the analysed modules. A violation surfaces as its
own **"Architecture Guard"** check instead of hiding in the 30-minute Build
job. Failure reporting uses the gradle exit code only — no `::error`
annotation, no auto PR comment — matching how `ci.yml` and `license.yml`
already behave.
`ci.yml` drops `:eventmesh-architecture-guard:test` from the matrix build so
the rules don't run twice.
## Commits
1. `5aab8a64` `feat(arch-guard): enforce rules via rule.check(classes)` —
WARN → FAIL, drop Logger/EvaluationResult imports, LOG field, stale Javadoc
2. `e9115ee4` `fix(arch-guard): correct meshmessage package in
protocol-hidden rules` — 3 package strings
3. `3b1fa6f9` `fix(arch-guard): drop broken ruleRuntimeTcpInternalNoReverse`
— rule + test
4. `59a992e1` `ci(arch-guard): dedicated Architecture Guard workflow` — new
workflow, `ci.yml` exclude, README
## Verification
```bash
./gradlew :eventmesh-architecture-guard:check
```
Local: **BUILD SUCCESSFUL** — 9/9 rules pass in FAIL mode, plus
compileJava/compileTestJava, checkstyle, pmd, spotbugs all clean. Both workflow
YAMLs parse cleanly.
## Note for reviewers
Because WARN mode never emitted anything, **no violation list was ever
published**, so this PR is the first time these rules have actually run. If any
team believes a specific rule is too strict, that is now a visible, discussable
failure rather than a silent one.
Refs: #5305. Builds on #5298 (PR #5320) and #5297 (PR #5321).
--
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]
