You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is about general dependency management hygiene and logical organization of it: what do you think about moving semconv's (io.opentelemetry.semconv/opentelemetry-semconv) dependency management from opentelemetry-instrumentation-bom to opentelemetry-bom?
From user perspective, opentelemetry-semconv should be next to opentelemetry-api (BOM-wise) since they are providing OTel "~interfaces" and both can be used without the Java instrumentation. This would also help making semconv more loosely coupled (one of OTel's core values) since right now, (logically/BOM-wise) it is a bit more coupled to instrumentation since it is in that BOM.
Describe the solution you'd like
Moving semconv's dependency management to opentelemetry-bom. Right now it is in opentelemetry-instrumentation-bom (see here) and semconv is used by users without instrumentation.
Describe alternatives you've considered
Not sure there is much, there are only two places for it, the current and opentelemetry-bom that I think is a better fit.
Additional context
I think this would not be a breaking change for users since opentelemetry-instrumentation-bom brings in opentelemetry-bom.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem?
It is about general dependency management hygiene and logical organization of it: what do you think about moving semconv's (
io.opentelemetry.semconv/opentelemetry-semconv
) dependency management fromopentelemetry-instrumentation-bom
toopentelemetry-bom
?From user perspective,
opentelemetry-semconv
should be next toopentelemetry-api
(BOM-wise) since they are providing OTel "~interfaces" and both can be used without the Java instrumentation. This would also help making semconv more loosely coupled (one of OTel's core values) since right now, (logically/BOM-wise) it is a bit more coupled to instrumentation since it is in that BOM.Describe the solution you'd like
Moving semconv's dependency management to
opentelemetry-bom
. Right now it is inopentelemetry-instrumentation-bom
(see here) and semconv is used by users without instrumentation.Describe alternatives you've considered
Not sure there is much, there are only two places for it, the current and
opentelemetry-bom
that I think is a better fit.Additional context
I think this would not be a breaking change for users since
opentelemetry-instrumentation-bom
brings inopentelemetry-bom
.The text was updated successfully, but these errors were encountered: