Why?
The OpenTelemetry project uses gradle. It also provides a Gradle plugin - Muzzle, that detects resources (classes) that are necessary to be on the classpath when the javaagent is run (avoiding constant NoClassDefFound/ClassNofFound exceptions). It also helps finding and using Virtual fields which we use extensively. If we use gradle, we could just use it and have codebase reduced - currently we manually list classes that should be included which is cumbersome.
Other reasons:
Potentially new gradle plugins could be developed by OTEL project and we could use them too
Gradle is easier to use (and faster?)
Alternatives:
Write our own sbt Muzzle plugin. This would require us to maintain it though which is a downside imho and a big distractor.
Why?
The OpenTelemetry project uses gradle. It also provides a Gradle plugin - Muzzle, that detects resources (classes) that are necessary to be on the classpath when the javaagent is run (avoiding constant NoClassDefFound/ClassNofFound exceptions). It also helps finding and using Virtual fields which we use extensively. If we use gradle, we could just use it and have codebase reduced - currently we manually list classes that should be included which is cumbersome.
Other reasons:
Potentially new gradle plugins could be developed by OTEL project and we could use them too
Gradle is easier to use (and faster?)
Alternatives:
Write our own sbt Muzzle plugin. This would require us to maintain it though which is a downside imho and a big distractor.