You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
=> binary class files can be found in: \META-INF\versions\9\io\opentelemetry\sdk\internal
this sounds like a cosmetic thing, but causes real-world problems. e.g. we have automated tooling to manage open source libraries and to check compliance with licensing conditions (where original source code artifacts are fetched and processed) - obviously, archives containing binary .class files are rejected as invalid/corrupted.
isn't a standard maven plugin used to package the sources jar before publishing a release into central maven repo? to be honest, can't even think of how this sort of mix of classes and sources can happen in practice - but apparently it does ;)
this issue is not unique to the 1.25.0 release of the artifact, i just used it as an example...
The text was updated successfully, but these errors were encountered:
for example:
https://repo.maven.apache.org/maven2/io/opentelemetry/opentelemetry-sdk-common/1.25.0/opentelemetry-sdk-common-1.25.0-sources.jar
=> binary class files can be found in: \META-INF\versions\9\io\opentelemetry\sdk\internal
this sounds like a cosmetic thing, but causes real-world problems. e.g. we have automated tooling to manage open source libraries and to check compliance with licensing conditions (where original source code artifacts are fetched and processed) - obviously, archives containing binary .class files are rejected as invalid/corrupted.
isn't a standard maven plugin used to package the sources jar before publishing a release into central maven repo? to be honest, can't even think of how this sort of mix of classes and sources can happen in practice - but apparently it does ;)
this issue is not unique to the 1.25.0 release of the artifact, i just used it as an example...
The text was updated successfully, but these errors were encountered: