Add arch test to detect usage of shared internal code

[jack-berg]

Related to #6970.

This test prints out instances of shared internal code use. We could eventually remove all the detected instances, at which point we could fail the build instead of just printing.

But there's a long way to go. See this gist for the current state of affairs.

Note: I don't currently have a good way to tell when internal code is referenced for things like the SDK's implementation of of opentelemetry-api-incubating, which is switched to a compile dependency in #6944.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.21%. Comparing base (62049e7) to head (3441b9a).
⚠️ Report is 94 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6978      +/-   ##
============================================
+ Coverage     90.15%   90.21%   +0.05%     
- Complexity     7476     7606     +130     
============================================
  Files           836      841       +5     
  Lines         22550    22923     +373     
  Branches       2224     2291      +67     
============================================
+ Hits          20331    20680     +349     
- Misses         1515     1526      +11     
- Partials        704      717      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jack-berg]

Resurrecting this and marking ready for review @open-telemetry/java-approvers.

There have been a number of topics coming up lately that reinforce the need to avoid shared internal code. A couple that come to mind:

• Add initial OSGi support #7964 need to export our *.internal.* packages even though we shouldn't. Blocked by Strengthen versioning requirements #6970.
• Deprecate zipkin exporter #7863 need to deprecate and eventually stop publishing zipkin exporter, but before we do, need to make sure its not using any shared internal code so users can continue to use old versions it without the risk of changes to shared internal code breaking it.

[jack-berg]

Here's the TODO list. All these modules use shared internal code.

In contrast, the list of modules which DO NOT use shared internal code is small:

• opentelemetry-common
• opentelemetry-context
• opentelemetry-tracing-shim
• opentelemetry-api
• opentelemetry-extension-kotlin
• opentelemetry-sdk

[trask]

this is what AI is saying and suggesting for me (and I've found it's a lot better at Gradle than me 😄)

The body of tasks.register {} is a configuration action, not an execution action. All of mkdirs(), createNewFile(), writeText() run at configuration time for every Gradle invocation, not when the task is actually executed. This should be wrapped in a doLast {} block to defer the side effects to execution time. As-is, the file is written even when the task is up-to-date or not requested.

The task does not declare inputs/outputs, so Gradle cannot perform up-to-date checking. Consider adding outputs.file(artifactsAndJarsFile) and inputs from jarTasks so that it is properly cached and only re-runs when jar outputs change.

Suggested change

	var writeArtifactsAndJars = tasks.register("writeArtifactsAndJars") {
	dependsOn(jarTasks)
	artifactsAndJarsFile.parentFile.mkdirs()
	artifactsAndJarsFile.createNewFile()
	val content = jarTasks.stream()
	.map {
	it.archiveBaseName.get() + ":" + it.archiveFile.get().toString()
	}.collect(Collectors.joining("\n"))
	artifactsAndJarsFile.writeText(content)
	}
	val writeArtifactsAndJars = tasks.register("writeArtifactsAndJars") {
	dependsOn(jarTasks)
	outputs.file(artifactsAndJarsFile)
	doLast {
	artifactsAndJarsFile.parentFile.mkdirs()
	val content = jarTasks.stream()
	.map {
	it.archiveBaseName.get() + ":" + it.archiveFile.get().toString()
	}.collect(Collectors.joining("\n"))
	artifactsAndJarsFile.writeText(content)
	}
	}

[jack-berg]

and I've found it's a lot better at Gradle than me

Yeah very helpful for demystifying gradle

[jack-berg]

This specific code ran into issues with the configuration cache. I iterated on it a bit and made it work.