Generate incubating metric name, unit, and description constants

[ADITYA-CODE-SOURCE]

Summary

Add metric constant code generation to the incubating semconv artifact.

This introduces {Namespace}IncubatingMetrics classes that expose metric name, unit, and description constants from the semconv metric model, following the existing Java semconv codegen organization and incubating-first rollout.

What this changes

• adds IncubatingSemanticMetrics.java.j2 for incubating metric constant generation
• wires incubating metrics generation into buildscripts/templates/registry/incubating_java/weaver.yaml
• adds a stable SemanticMetrics.java.j2 scaffold for follow-up work
• keeps stable metrics generation disabled for now by leaving the buildscripts/templates/registry/java/weaver.yaml entry commented out
• generates new *IncubatingMetrics.java classes under semconv-incubating

Generated API shape

Each metric generates three constants:

public static final String HTTP_SERVER_REQUEST_DURATION_NAME =
    "http.server.request.duration";
public static final String HTTP_SERVER_REQUEST_DURATION_UNIT = "s";
public static final String HTTP_SERVER_REQUEST_DURATION_DESCRIPTION =
    "Duration of HTTP server requests.";

Example generated class:

public final class HttpIncubatingMetrics {
  /** Name of the {@code http.server.request.duration} metric. */
  public static final String HTTP_SERVER_REQUEST_DURATION_NAME =
      "http.server.request.duration";

  /** Unit of the {@code http.server.request.duration} metric. */
  public static final String HTTP_SERVER_REQUEST_DURATION_UNIT = "s";

  /** Description of the {@code http.server.request.duration} metric. */
  public static final String HTTP_SERVER_REQUEST_DURATION_DESCRIPTION =
      "Duration of HTTP server requests.";

  private HttpIncubatingMetrics() {}
}

Why incubating only

Per maintainer guidance, the pattern itself is being introduced experimentally first.

Even when the underlying metric semconv is stable, the generated Java metric constants are introduced in opentelemetry-semconv-incubating first so the class layout, naming, and API shape can be reviewed before promoting stable generation into opentelemetry-semconv.

Validation

Locally verified with:

• ./gradlew clean generateSemanticConventions --console=plain
• ./gradlew spotlessApply
• :semconv-incubating:compileJava
• :semconv-incubating:checkstyleMain
• :semconv-incubating:spotlessCheck
• :semconv:compileJava
• :semconv:checkstyleMain
• :semconv:spotlessCheck

Follow-up

Once the pattern is approved, a follow-up PR can:

• enable stable metrics generation in semconv
• decide whether incubating stable copies should be deprecated
• build any richer metric helper APIs on top of these constants

References

• Related to [Question] Semantic convention metrics #365
• Builds on the pattern explored in Generate constants for metric definitions #317

cc @jack-berg

[geekdave]

✅ Verified with a local gradle build that I am now able to reference the previously-unavailable semconv metric name:

import static io.opentelemetry.semconv.incubating.HttpIncubatingMetrics.HTTP_SERVER_REQUEST_DURATION_NAME;

[ADITYA-CODE-SOURCE]

✅ Verified with a local gradle build that I am now able to reference the previously-unavailable semconv metric name:

import static io.opentelemetry.semconv.incubating.HttpIncubatingMetrics.HTTP_SERVER_REQUEST_DURATION_NAME;

Thanks for testing, @geekdave! Glad it works for your use case.

[jack-berg]

@trask's code in from #317 has additional logic to add deprecated javadoc tags which link to the stable class if available. This will be necessary once we enable enable generation of stable classes.

I pushed a commit which ports those changes to this branch: jack-berg@0ef14f8

Should probably just leave the code, but comment out the bit that makes the linking work with a TODO reminder to enable when generation of stable classes is enabled.

Speaking of which, given our experience with generating attribute constants, I'm much less worried about us getting the generation pattern wrong in some key way we'll regret. @trask / @laurit WDYT about just enabling generation of stable metrics out of the gate?

[ADITYA-CODE-SOURCE]

Thanks @jack-berg — this is very helpful.
I can bring over the deprecated-javadoc logic from #317 as you suggested.
On the broader question of enabling stable metrics in this PR as well, I’m happy to follow whichever direction you all prefer. The stable path is already scaffolded, so I can either keep this incubating-only for now or fold stable generation into this PR if that seems like the better direction.