Open rjbaucells opened 1 year ago
hi @rjbaucells! this sounds good, can you review https://github.com/open-telemetry/opentelemetry-java/pull/781 and propose something similar in this repo?
Sure, I can do a similar PR in this repo. Now, what should be the module naming convention?
io.opentelemetry.instrumentation.log4j.appender
io.opentelemetry.instrumentation.logback.appender
this looks good to me 👍
we might want to include the "base version" as well, since we include that in the artifact and package names, so that we can change the supported base version in the future without introducing breaking changes
The module name should not contain version, it should follow same guidelines as package name and must be the same from version to version. Two modules cannot export the same package name (JVM will not load the application).
we use "base version" to refer to the lowest version of the instrumented library that the instrumenation supports, e.g.
this "base version" is also encoded in the artifact name, e.g.
there's also some more context in https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/932#issuecomment-1209349496
Adding specific examples:
instrumentation\log4j\log4j-appender-1.2
instrumentation\log4j\log4j-appender-2.17
Could share the same module name io.opentelemetry.instrumentation.log4j.appender
since they cannot be loaded together in the same JVM process (both log4j versions export the same package name org.apache.logging.log4j.*
). Java module system enforces it.
I can add the same naming convention as the package name... but I think it will bring more problems in the future. Changing a dependency version requires the update of the module-info.java
files.
The module name should not contain version, it should follow same guidelines as package name and must be the same from version to version. Two modules cannot export the same package name (JVM will not load the application).
The "base version" is not the version of the instrumentation library; it's the minimum supported version of the instrumented library, and we normally encode it as part of the package/artifact name precisely to avoid conflicts. I strongly think that the Automatic-Module-Name
should correspond with the gradle module name (or, instrumentation name) and include the base version.
OK, I will use the same convention as in the package name.
Modern Java applications (JDK 9+) should use modules for encapsulation and easy dependency management. The first step libraries should take (without breaking compatibility with old JDK versions) is providing a module name in the
META-INF\MANIFEST.MF
file. The level of effort is low and will remove unnecessary warning messages in applications consuming it. e.g.:Using the
MANIFEST.MF
Automatic-Module-Name
header will remove the above warning from consumer applications: e.g.:OpenTelemetry API and SDK already provide this configuration in the
MANIFEST.MF
files.I can provide
PR
for adding such names once the naming convention is agreed upon.