Remove muzzle from gradleplugins #4183
Conversation
iNikem
requested review from
anuraaga,
jkwatson,
laurit,
mateuszrzeszutek,
pavolloffay,
trask and
tylerbenson
as code owners
| generation phase. These classes become part of the code that plugin inspects and traverses during | ||
| references collection phase. | ||
| */ | ||
| add("codegen", "io.opentelemetry.javaagent:opentelemetry-javaagent-tooling") |
There was a problem hiding this comment.
Just wondering: we already have this in the javaagent-instrumentation plugin, why do we need to duplicate it here?
There was a problem hiding this comment.
Yes, testing-common:integration-tests applies otel.javaagent-testing convention (which applies this one), but does not apply javaagent-instrumentation convention
There was a problem hiding this comment.
IIRC, which I might not :P, I think we said that we don't want this artifact on the muzzle check's transformation classpath. Is that not an issue anymore, or is that not what happens with this change?
There was a problem hiding this comment.
"This" - you mean "tooling"? io.opentelemetry.instrumentation.javaagent-instrumentation.gradle.kts always included tooling to codegen conf. Or do I miss something?
There was a problem hiding this comment.
Oh ok - previously for javaagent-testing.gradle.kts it was picking it up through the build.gradle dependencies but now both of them use the configuration? Cool
There was a problem hiding this comment.
What I don't fully understand, is if we need muzzle-generation plugin at all in io.opentelemetry.instrumentation.javaagent-testing.gradle.
There was a problem hiding this comment.
At least one of our test projects includes a test instrumentation so it doesn't work without the codegen.
| generation phase. These classes become part of the code that plugin inspects and traverses during | ||
| references collection phase. | ||
| */ | ||
| add("codegen", "io.opentelemetry.javaagent:opentelemetry-javaagent-tooling") |
There was a problem hiding this comment.
IIRC, which I might not :P, I think we said that we don't want this artifact on the muzzle check's transformation classpath. Is that not an issue anymore, or is that not what happens with this change?
* Include gradle-plugins as a composite build * Make gradle-plugins project independent from the main one * Delete old ClassRef and friends * Fixes * Polish * Polish * Simplify
Several changes in this PR.
First,
buildSrcwas renamed toconventionsand included into the main build as a composite.This allows for the second change: include
gradle-pluginsintoconventionsas a composite build. This way we can substitute maven dependencies on gradle plugins artifacts with local project dependency and always use the latest version of it.Third, all classes that actually depend on our main project were removed from
gradle-pluginsmodule and moved tomuzzle. This completely breaks the cycle between main project and plugins and allows us always use the latest version of our code without intermediate publishing. The only interface between them is now a name of the classio.opentelemetry.javaagent.tooling.muzzle.generation.MuzzleCodeGenerationPlugin