generateApolloSources fails with NoSuchMethodError after 3.6.2 -> 3.7.1 update #4523
Comments
|
Hi! This is odd, I'm unable to reproduce it on a simple project and just to be sure I've checked that I can see the method in the plugin's jar. Have you tried the usual clean / invalidate / kill gradle daemon / etc.? Also it may be interesting to see if you still see the issue with the |
|
I tried 3.7.0 has a new experimental feature Let me describe our project a bit more in case it helps to detect the issue.
I will keep digging further and see if it's feasible to reproduce this issue in a simple project that mimics our structure. |
|
Thank you for giving more information, this is helpful! I've managed to reproduce the issue when using both v2 and v3 in the same project! The cause of the issue is that both versions relocate dependencies to the same package Using |
You are right, I replaced only plugin id, but forgot about dependency in our convention plugin. My bad 😞 I can confirm that after changing plugin id Now I face a compilation issue. Compiler cannot find generated class. I see that class was generated. Even Android Studio sees the generated code and is able to add import to it. Still compilation fails. Do I need to do any extra configuration steps when using I compared |
Good to hear! About the new issue - no, the configuration is the same, the only difference with this version of the plugin is that it doesn't relocate the dependencies. I can't seem to reproduce on my side, is there a way you could try to replicate your setup in a simple project that we can have a look at? |
|
I want to dig a bit deeper to see if I can find any explanation. If not, then I'll try to replicate our setup in a small project. This will take some time. So far I tried the following experiments:
|
|
I was able to compile with version 3.7.1 after disabling our internal convention plugin and configuring Apollo directly in |
|
Thanks for this. Interesting! Wondering why this would impact the sourceSet 🤔 |
|
I found that error is also related to When Apollo plugin is applied in afterEvaluate project.afterEvaluate {
pluginManager.apply("com.apollographql.apollo3")
extensions.configure(com.apollographql.apollo3.gradle.api.ApolloExtension::class.java) {
service("MyService") {
packageName.set("com.example.rocketreserver")
}
}
}then compilation passes on When configuration is changed to project.afterEvaluate {
pluginManager.apply("com.apollographql.apollo3")
extensions.configure(com.apollographql.apollo3.gradle.api.ApolloExtension::class.java) {
packageName.set("com.example.rocketreserver")
}
}then compilation passes on When Apollo plugin is configured right away, but using plugins {
id("com.apollographql.apollo3").version("3.7.1")
}
apollo {
service("MyService") {
packageName.set("com.example.rocketreserver")
}
}then compilation passes on |
|
Thank you so much for taking the time to dig more on this, and providing a repro project! Was there a specific need for you to call the plugin apply in |
Our goal is to simplify Apollo setup and ensure configuration is aligned between different Gradle modules. That's why our plugin has an extension similar to this: myPlugin {
apollo {
rootPackage = "com.example.xyz"
}
}It exposes only a small subset of options, the rest is unified. I couldn't find any other alternative except using |
|
I see. In fact I remember having a similar issue when setting up convention plugins in the Apollo project. In the end we decided to explicitly applying plugins at the call site instead of applying them in our custom plugin. Not saying what you're trying to do is not possible though 😅 But |
The traditional solution to this is to expose functions in your extension. The class MyApolloConfiguration {
var packageName: String? = null
}
class MyPluginExtension {
fun apollo(action: Action<MyApolloConfiguration>) {
val myApolloConfiguration = MyApolloConfiguration()
action.execute(myApolloConfiguration)
project.apply(plugin = "com.apollographql.apollo3")
project.extension.getByType(ApolloExtension::class.java).packageName = myApolloConfiguration.packageName?: error("no packageName specified")
}
}This way, you stay in control of when the plugin is applied and it's not relying on the |
|
That's a great solution @martinbonnin ! It's a shame I couldn't figure out it myself :( I close the issue. Switching @BoD @martinbonnin Thank you for your help. I appreciate it a lot! |
|
Thanks for reporting this and the thorough investigations 🙏 . We will replace the relocation prefix for v3 too so that both plugins can co-exist. |
|
This is now available in version |
Summary
After update to 3.7.1
myModule:generateApolloSourcestask fails withOn 3.6.2 compilation succeeds.
Version
3.7.1
Logs
Steps to reproduce the behavior
Apollo version change is the only change introduced. Unfortunately, I cannot share project. Project uses Kotlin 1.7.20. I tried to update to Kotlin 1.7.21,
generateApolloSourcesstill fails.The text was updated successfully, but these errors were encountered: