Instrumentation extension plugin

[jaydeluca]

@SylvainJuge raised a question in slack about whether we could eliminate the need for declaring the muzzle dependencies when using the muzzle plugins, and in general just make it easier to get started with extensions.

This change publishes a new gradle plugin io.opentelemetry.instrumentation.javaagent-extension that packages up the 2 muzzle plugins and their associated dependencies.

In our example, it can replace these lines, and then remove the need for these lines entirely. I will followup with updating the example code once this has been published

[SylvainJuge]

This is exactly what I was looking for, do you think we should also include the following ?

• shadow plugin, as shading libraries will always be something required, and not doing this tends to create unexpected behaviors if you are not familiar with them.
• otel bom platform dependencies, so that by default the plugin version transitively provides the expected version and thus prevents version mismatch by default.

As an added benefit this also provides us a future hook to help with maintenance of extensions, for example if we need to change something in the packaging for indy.

[laurit]

perhaps it would be better if the existing plugins could automatically add these instead of introducing a new plugin?

[jaydeluca]

@SylvainJuge :

do you think we should also include the following ?

• shadow plugin, as shading libraries will always be something required, and not doing this tends to create unexpected behaviors if you are not familiar with them.
• otel bom platform dependencies, so that by default the plugin version transitively provides the expected version and thus prevents version mismatch by default.

For the shadow plugin, is your idea that we configure it, or just package it? it's also already included transitively via the muzzle check plugin.

for the bom dependencies, it gets a little complicated, but I do have a POC mostly working. Im not sure how the default behavior should be. I implemented the change that @laurit suggested, moving the dependency resolution into the muzzle plugins themselves, and then I tried implementing some logic so that we can handle cases where a user wants to override the BOM.

The tricky part was getting the plugin to know its own version at runtime. I found a way around this by generating a properties file at build time and embedding it in the plugin JAR. I' not sure if this is a good approach or not.

In my POC, you can set the helper plugin

  plugins {                                                                                                                                                                        
    id("io.opentelemetry.instrumentation.javaagent-extension") version "2.24.0-alpha"                                                                                 
  }                                                                                                                                                                                

and then and then the user can override it if they want

  dependencies {                                                                                                                                                                                                                                                                         
    implementation(platform("io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha:2.22.0-alpha"))                                                              
  }                                                                                                                                                                                

implementation extends compileOnly, so the user's BOM declarations will take precedence over the plugin's auto-applied versions.

So i guess we should decide if we want to support this, or just leave the two muzzle plugins with the new logic to auto resolve their dependencies?

[SylvainJuge]

For the shadow plugin, is your idea that we configure it, or just package it? it's also already included transitively via the muzzle check plugin.

I am definitely not a gradle expert here.

If the user does not have to do any configuration, then I think we can configure it for them to avoid copy/paste, if there are still things they need to customize then it could maybe simpler to just leave it as part of the example.