Hi, we have a custom Gradle convention plugin to p...

# apollo-kotlin

[Jan Skrasek]

Hi, we have a custom Gradle convention plugin to pre-setup ApolloExtension.
However, with compulsory service name definition, "later" we are unable to modify the plugins configuration in the actual gradle.kts file - as the service has to be defined at once. What is the solution here?

[bod]

Hi! Are you referring to the change in 3.7.2 that options should be in the service block?

[bod]

If you have only one service you can hardcode the name in the convention plugin.

[Jan Skrasek]

Yes, that's it. The name resolution is not a problem (we can resolve it dynamically, that's ok).
The issue is, that the service configured by convention plugin should be possible to "additionally" configure it directly in the module the plugins is applied on.

[Jan Skrasek]

This is what we're doing in our convention plugin:

project.extensions.configure<com.apollographql.apollo3.gradle.api.ApolloExtension> {
    val packagePath = "com.example" + path.replace(":", ".") + ".network"
    packageName.set(packagePath)
    codegenModels.set("responseBased")
    generateOptionalOperationVariables.set(false)
    generateAsInternal.set(true)
  }

  dependencies {
    withVersionCatalog { libs ->
      add("implementation", libs.apollo.runtime)
    }
  }

[Jan Skrasek]

And then the actual gradle.kts may modify it further:

apollo {
  generateTestBuilders.set(true)
}

But adding services (with the same name) creates the problem

[bod]

oh right, because the service block actually creates a service, so calling it multiple times won't work

[bod]

you could pass the options to your convention plugin, by calling methods on its extension

[Jan Skrasek]

Yeah, I tried something like that but I had a problem that my extension is "filled" with setup later than calling configure in the convention plugin. But maybe this is just a thing I could somehow configure, but I don't know how.

[bod]

could you call the setup from the configuring method as well?

[Jan Skrasek]

I may not understand the question. I think this is the step progression:

• gradle.kts is loaded
• its convention plugin registers own extension
• its convention plugin is applied
• convention plugins apply apollo plugin
• convention plugins call configure with lambda
• that lambda executes
• all plugins configure, gradle.kts continues
• there is own extension block -> its triggered
So basically the custom gradle.kts setup happens later than configure. Mabye we could delay the apollo's configure call.

[bod]

Mabye we could delay the apollo's configure call.

that's what I meant 👍

so something like:

• gradle.kts is loaded
• its convention plugin registers own extension
• its convention plugin is applied
• convention plugins apply apollo plugin
• convention plugins call configure with lambda
• that lambda executes
• all plugins configure, gradle.kts continues
• there is own extension block -> its triggered
◦ convention plugins call configure with lambda
◦ that lambda executes

[mbonnin]

+1 to @bod's suggestion above. There can be only one service {} block.
If it's in your convention plugin, then your convention plugin now "owns" the Apollo plugin and you'll have to pass any configuration you want to set in individual build scripts to your convention plugin.

I understand how that's misleading because the DSL syntax could make you think that it's "declarative" while in reality everything is "imperative". We've looked at this from all directions and haven't really found a better solution. It's either that or weird scheduling/interop issue

[Jan Skrasek]

When I'm thinking about this should be doable so I'll recheck the impl I had 🙂

[Jan Skrasek]

Thank you!

[mbonnin]

Sure thing! Thank you for bringing that up! 🙂