hey im running into a weird issue (in :thread: ). I have a gradle plugin i wrote that depends on apo...

# apollo-kotlin

[agrosner]

hey im running into a weird issue (in 🧵 ). I have a gradle plugin i wrote that depends on apollo ast to use similiar parsing mechanisms as main apollo plugin. seems I cannot run generateApolloSources when the plugin is included.

[agrosner]

Execution failed for task ':infra-apollo-schema:generateMonolithApolloSources'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:142)
	at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:140)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:128)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
	at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	at 
Caused by: java.lang.NoSuchMethodError: 'com.apollographql.relocated.xb com.apollographql.apollo3.ast.introspection.Introspection_to_schemaKt.toSchemaGQLDocument(java.io.File)'

[agrosner]

i verified im using 3.6.2 everywhere in dependencies to ensure there isnt a mismatch

[agrosner]

and its here in the dependency….weird

[agrosner]

we depend on the ast artifact directly. should we depend on the gradle plugin instead? seems to bundle the ast in its package..

[mbonnin]

This seems related to https://github.com/apollographql/apollo-kotlin/commit/c33eb7fcc8d0ff5a46aa67d4b73f65f29

[mbonnin]

(but that's only on 3.7.x 🤔 )

[mbonnin]

Alright, forgot what I said. It's because the relocated Gradle plugin keeps com.apollographql.apollo3.ast.introspection.Introspection_to_schemaKt.toSchemaGQLDocument . See https://github.com/apollographql/apollo-kotlin/blob/c8227a768e0a6ee4041f81a4a7f1793e1e8a988f/apollo-gradle-plugin/rules.pro#L28

[mbonnin]

apollo-gradle-plugin.jar shadows apollo-ast.jar and in that case, it relocates the return value GQLDocument but not the method name itself (toSchemaGQLDocument )

[mbonnin]

So when you load apollo-ast.jar , you end up with duplicate toSchemaGQLDocument . One that returns a GQLDocument and one that returns a com.apollographql.relocated.xb

[mbonnin]

We can try to relocate more of the internals of the plugin to avoid such clashes in the future.

In the meantime, you can use the com.apollographql.apollo3.external (apollo-gradle-plugin-external) plugin that doesn't do any relocation

[mbonnin]

It's better anyways because it will use less memory. The trade off is that you can now have name clashes non-apollo dependencies like okio and antlr (see https://issuetracker.google.com/issues/183511640)

[agrosner]

oh sure thing. thank you for your help. ill check it out. I figured some shadowing was going on, but didnt know if there was a good solve for itl

[agrosner]

i could migrate to 3.7.x. is that a fix as well?

[agrosner]

or are you saying that it will have same issue as 3.6.2

[mbonnin]

3.7.x will have the same issue, we'll work on a fix but there's nothing in 3.7.2 yet

[agrosner]

ok!

[mbonnin]

And in all cases, if you can get the external version to work, it will save your builds some RAM because the JVM will not have to load all these classes multiple times

[agrosner]

oh yeah thats good to know. and that makes sense.

[mbonnin]

Gradle loves that Metaspace memory of yours 😅

[agrosner]

haha yeah…we bumped our project gradle max heap to 16g now from 8. our release builds were getting OOM

[agrosner]

wayfair app is decently large with 100+ modules.

[agrosner]

its not a huge blocker at the moment. what we’re doing is building a plugin to analyze graphql usage in our app accross apollo and non apollo usage and output usage statistics and postman collections. pretty ambitious!

[mbonnin]

That is very cool! I always wanted to do something like this in Apollo

[mbonnin]

Like ./gradlew generateApolloStatistics that shows # of queries, field useds, etc...

[agrosner]

yeah. we had a lot of parallel team development over the years and so theres a lot of duplicated query structures

[agrosner]

that would be awesome!

[agrosner]

i also generate an output json that feeds into a simple static material react app that you can browse internally too.

[mbonnin]

wow

[mbonnin]

Very cool 👏

[mbonnin]

Want to contribute it 😇 ?

[agrosner]

thank you!

[agrosner]

ohh that would be interesting.

[mbonnin]

I'm sure a lot of users would find this usefull

[agrosner]

i may consider your offer 😄 , i dont know if I can devote so much time at the moment, so I cant promise right away

[agrosner]

here’s my github

[mbonnin]

Feel free to send a draft or a gist. Then we can work together on polishing it/including it in the main repo.