Conversation
|
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? |
|
It worked for me experimentally (as in, I published to maven-local and applied my gradle plugin in a different project). |
|
@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! |
Not that I'm aware of. The compiler-plugin artifact just doesn't have any dependencies, there's only a 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. |
|
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 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 |
Fixes #23
The shadow plugin defaults seem to work just fine! It plays nicely with
compileOnlyand everything