Inline incubating semconv attributes

[trask]

Follow-up to @laurit's #1585 (comment)

[breedx-splk]

I think I must have missed something in the comment...why is it desirable to copy/duplicate these constants?

[trask]

https://github.com/open-telemetry/semantic-conventions-java?tab=readme-ov-file#published-releases

This artifact has the -alpha and comes with no compatibility guarantees. Libraries can use this for testing, but should make copies of the attributes to avoid possible runtime errors from version conflicts.

[breedx-splk]

https://github.com/open-telemetry/semantic-conventions-java?tab=readme-ov-file#published-releases

This artifact has the -alpha and comes with no compatibility guarantees. Libraries can use this for testing, but should make copies of the attributes to avoid possible runtime errors from version conflicts.

So the entire purpose here is to avoid taking a dependency on an artifact with -alpha in the suffix? I'd rather do that than have copies of the values that could deviate from the semconv over time....

Maybe we figure that the tests (which use the -alpha) give us enough confidence?

[trask]

we're worried about diamond dependency problem where some users will end up depending (transitively) on different irreconcilable versions of the semconv alpha artifact

Maybe we figure that the tests (which use the -alpha) give us enough confidence?

yeah, though it would be interesting to validate this

[laurit]

The guidance given in https://github.com/open-telemetry/semantic-conventions-java/blob/main/README.md states that

Libraries can use this for testing, but should make copies of the attributes to avoid possible runtime errors from version conflicts.

[trask]

@breedx-splk I'm going to merge since this is the (current) convention in this repo, but we can revisit