Skip to content

Add shadow plugin#37

Draft
kyay10 wants to merge 1 commit intoKotlin:masterfrom
kyay10:shadow
Draft

Add shadow plugin#37
kyay10 wants to merge 1 commit intoKotlin:masterfrom
kyay10:shadow

Conversation

@kyay10
Copy link
Contributor

@kyay10 kyay10 commented Jan 13, 2026

Fixes #23

The shadow plugin defaults seem to work just fine! It plays nicely with compileOnly and everything

@bnorm
Copy link
Member

bnorm commented Jan 13, 2026

I don't think this quite fixes #23. We need to now make sure the shadowed jar is used as the compiler plugin artifact in the Gradle plugin. Last time I used tthe shadow Gradle plugin, it produced a secondary jar artifact rather than replacing the primary jar. Is that still the case or is the shadowing happing in the produced artifact?

@kyay10
Copy link
Contributor Author

kyay10 commented Jan 13, 2026

It worked for me experimentally (as in, I published to maven-local and applied my gradle plugin in a different project).
Looking at the docs, it seems like a little more config is needed, so I'll add it (strange that it worked without it for me).
Edit: running into some issues figuring out how to include sources and javadoc jars alongside the shadowed jar...
Edit 2: Okay, so it turns out that the shadow plugin wasn't doing anything in my setup. Yet, it seems that compiler plugin classpath is now transitive by default?? 😵‍💫.

@Mr3zee
Copy link
Member

Mr3zee commented Jan 13, 2026

@kyay10 sorry to tag you here (and Brian also sorry for polluting the PR), but may I please ask you to check the internship emails? There is a time limit for scheduling interview and you may miss it, in which case we won't be able to proceed with the application this time. Thanks!

@kyay10 kyay10 marked this pull request as draft January 14, 2026 01:40
@bnorm
Copy link
Member

bnorm commented Jan 14, 2026

Yet, it seems that compiler plugin classpath is now transitive by default?? 😵‍💫.

Not that I'm aware of. The compiler-plugin artifact just doesn't have any dependencies, there's only a compileOnly dependency on the compiler itself. So the shadow plugin should effectively produce the same result, since there's quite literally nothing to shadow.

It would make a good test, though, if we add a used dependency in the compiler-plugin artifact and make sure it works in a sample project.

@kyay10
Copy link
Contributor Author

kyay10 commented Jan 14, 2026

That's the thing, I've been testing with a plugin that has a dependency! I have a plugin that uses Arrow internally, and in ways that definitely require runtime usage (i.e. the uses aren't just inline), and it's working without neither shadowing nor any other workarounds to force transitivity!?! In fact, running the gradle dependencies task shows that, indeed, gradle pulled in Arrow as a dependency of the compiler-plugin in the XPluginClasspath configuration.

Regardless, I think the right approach here is shadowing. I just need to figure out how to get the sources and javadoc jars to be attached to components["shadow"]. I'll undraft the PR once I've figured that out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add transitive compiler plugin classpath workaround

3 participants