Investigate whether we can / should relocate semconv in maven before removing

[jack-berg]

Discussed #5807 in the 9/21/23 Java SIG and the possibility of using maven relocation to redirect users to the new coordinates before removing.

Investigate to determine if there is an increase in visibility to the user besides the deprecation notices that already exist.

[jack-berg]

Let's look at an example project which has used the maven relocation strategy:

• org.hibernate:hibernate-core relocated to org.hibernate.org:hibernate-core as of version 6.0
• New versions of the old group id org.hibernate:hibernate-core continue to be published with a POM (no jar) which includes the syntax to point to the new location. See this for example.
• The new group id org.hibernate.org:hibernate-core has the full artifacts for 6.x+.
• If I depend on org.hibernate:hibernate-core:5.6.15.Final and upgrade to org.hibernate:hibernate-core:6.0.0.Final, I don't get any sort of warning or error message, and I am silently upgraded to org.hibernate.org:hibernate-core:6.2.6.Final (new groupId, later version than what I thought I was getting).
• If a depend on the now deprecated io.opentelemetry:opentelemetry-semconv, I get a compile message like: Note: /Users/jberg/code/example/src/main/java/com/jberg/Application.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details.

I don't think we should do maven relocation:

• It requires ongoing published surface area
• It silently upgrades to the new location and to surprising version (not the one I requested and also not the latest)
• Its inconsistent with how we've handled location changes in the past for both experimental and stable artifacts
• IMO, the value it provides isn't offset by the effort involved to develop the required tooling in this repo