[Java] Build rocketmq-proto from submodule instead of depending on Maven Central

[lizhimins]

Summary

Add a proto module to the Java Maven reactor that compiles .proto files from the protos/ submodule (rocketmq-apis) into a rocketmq-proto JAR, replacing the dependency on a pre-published Maven Central artifact.

Closes #1286

Changes

1. Update protos/ submodule to latest main (bc8e184), which includes the client_properties field from rocketmq-apis#108.
2. Add java/proto/pom.xml using protobuf-maven-plugin to compile the 3 .proto files (definition.proto, service.proto, admin.proto) and generate gRPC stubs.
3. Add proto as the first module in the parent POM reactor build order, so downstream modules (client-apis, client, client-shade) resolve rocketmq-proto from the reactor instead of Maven Central.
4. Update CI workflows (java_build.yml, java_coverage.yml) to checkout submodules with submodules: recursive.

Why

• PR [Java] Support client properties for observability and management #1237 bumped rocketmq-proto to 2.2.0, but that version is not yet published to Maven Central, causing all Java CI jobs to fail.
• Other language clients (C++, Rust, C#, Node.js) already compile proto from the submodule. Java should follow the same pattern.
• This decouples Java client development from proto release cycles.

Build Order

proto (compile .proto from protos/ submodule)
  → client-apis
    → client (noshade)
      → client-shade
        → test

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 53.67%. Comparing base (4076e2b) to head (fa5742d).
⚠️ Report is 144 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1287      +/-   ##
============================================
+ Coverage     53.26%   53.67%   +0.40%     
- Complexity      651      785     +134     
============================================
  Files           208      221      +13     
  Lines         14303    14466     +163     
  Branches       5845     5577     -268     
============================================
+ Hits           7619     7764     +145     
+ Misses         6308     6303       -5     
- Partials        376      399      +23     

Flag	Coverage Δ
java	61.93% <ø> (+0.24%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RockteMQ-AI]

Review by github-manager-bot

Summary

This PR adds a proto module to the Java Maven reactor that compiles .proto files directly from the protos/ git submodule, replacing the dependency on a pre-published rocketmq-proto artifact from Maven Central. This decouples Java client development from proto release cycles and aligns Java with other language clients (C++, Rust, C#) that already compile proto from the submodule.

Findings

• [Info] java/proto/pom.xml:63 — protobuf-maven-plugin version 0.6.1 is used. This is the latest release of the plugin and works well, but note that the plugin has been relatively inactive. If you ever need newer protoc features, consider evaluating io.github.ascopes:protobuf-maven-plugin as a modern alternative. Not blocking.

• [Info] java/pom.xml:52 — The rocketmq-proto version is now tied to ${project.version} (5.2.1), whereas previously it was an independent 2.1.2. This is correct for reactor builds, but if anyone tries to consume rocketmq-proto as a standalone artifact published separately in the future, the version coupling may cause confusion. Consider adding a brief comment in the POM explaining this design choice.

• [Info] .github/workflows/java_build.yml and .github/workflows/java_coverage.yml — CI checkout steps correctly add submodules: recursive. I verified that all checkout steps across both workflows are updated (2 in java_build.yml, 1 in java_coverage.yml). Good.

• [Info] java/proto/pom.xml:62 — protoSourceRoot uses ${project.basedir}/../../protos, which correctly resolves from java/proto/ → repo root → protos/. The path is correct.

• [Info] java/proto/pom.xml — Checkstyle, SpotBugs, and JaCoCo are all correctly skipped for the generated proto code. This is appropriate since generated code should not be linted or counted for coverage.

Suggestions

1. Minor: Consider pinning the protos submodule commit in a comment or README so contributors know which rocketmq-apis SHA is expected. The submodule pointer update (68c2cc9 → bc8e184) is clear in the diff, but a note in java/proto/pom.xml or a top-level README would help future contributors understand the relationship.

2. Minor: The java_build.yml uses actions/checkout@v3 while java_coverage.yml uses actions/checkout@master. Consider standardizing on a pinned major version (e.g., @v4) for reproducibility. This is pre-existing and not introduced by this PR, just a general observation.

Overall

The change is clean, well-structured, and solves a real CI breakage (PR #1237 bumped proto to 2.2.0 which isn't on Maven Central yet). The approach matches what other language clients already do. LGTM.

---

Automated review by github-manager-bot

[qianye1001]

LGTM