#4661 discusses whether this repository is the right home for several components, including opentelemetry-sdk-extension-aws (AWS resource providers), and by extension opentelemetry-sdk-extension-resources.

I'd like to separate out the conversation about the resource providers to this issue to reduce the noise.

The current top candidate is to move resource providers to opentelemetry-java-instrumentation. Resource providers are similar to other instrumentation in the sense that they implement the semantic conventions. And the presence of vendor specific resource providers suggests that this repository is not the right home for these, since opentelemetry-java should not house vendor specific code requiring special knowledge to review.

The challenge to moving to opentelemetry-java-instrumentation is primarily one of artifact coordinates and package names. opentelemetry-sdk-extensions-resources is stable. If we move it to instrumentation, we can either give it new coordinates and package names that align with the pattern of that repo, or retain the existing coordinates and break uniformity. Retaining the same coordinates does mean that we can fully remove the code from this repo, which saves us from having to maintain two copies of the code going forward. (Note, this code is likely to change going forward given the instability of resource semantic conventions.) And if we retain the existing coordinates, then that begs the question of how to name new resource provider artifacts in the future: they can align with the other instrumentation artifacts or with the exception resource provider artifacts.

The other option is to move to opentelemetry-java-contrib, but I can't come up with a convincing argument for that route so I'll abstain. Perhaps someone else can 🙂 .