I upgraded to Apollo 3.7 and set up used coordinat...
# apollo-kotlin
e
I upgraded to Apollo 3.7 and set up used coordinates, and ran into something which might be a bug, but I am not sure. Either way, it was interesting. Basically, given an
interface A { foo: X, bar: Y}
and a type that implements it
type B implements A { foo: X, baz: Z}
, and a
fragment F on A { foo, bar, ...on B { baz }}
, then
BBuilder
will only have a field for
baz
. Shouldn't
foo
and
bar
be also added to the builder? How else would you define their values? 😄
👀 1
Btw, my workaround was to re-write the fragment like
fragment F on A {  ...on B { foo, bar, baz }}
m
That makes sense.
Another workaround is to add the
B.foo
and `B.bar`coordinates to
alwaysGenerateTypesMatching
e
oh, yeah. but I guess that the expected thing would be to have them added to the builder by default, no?
m
yea, you're 100% right
every interface field needs to pull all the implementation fields
Looking into it
l
I think we encountered this too..
m
We do have some code though...
Mmm this is done while merging the fields but not when computing used types from other modules
If that works for you, we'll make a patch release
e
I can test it tomorrow, for now I went with your suggested workaround 🙂
Hmm, I am trying to run
publishToMavenLocal
, but I get a bunch of errors:
Copy code
* What went wrong:
Script compilation errors:

  Line 001: import JapiCmp.configureJapiCmp
                   ^ Unresolved reference: JapiCmp

  Line 094:     checkGitStatus()
                ^ Unresolved reference: checkGitStatus

  Line 119: rootProject.configureNode()
                        ^ Unresolved reference: configureNode

  Line 120: rootProject.configureJapiCmp()
                        ^ Unresolved reference: configureJapiCmp
Any idea what could be wrong? 😞
It seems like Gradle doesn't pick up
build-logic
😕
m
Mmm, that's unexpected...
What commit are you on?
(I'm at
adccf1360de92d00e7ce93d4c5a825532f310769
)
e
same:
Your branch is up to date with 'origin/fix-used-coordinates-on-interfaces'.
Copy code
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
Intel Mac, if it matters
m
rm -rf */build **/**/build
I've seen it a couple of times where the build-logic jar becomes empty
Not 100% sure what the cause may be
e
well, that didn't help. build-logic.jar gets regenerated, but it's only 884 bytes, is that normal?
unzipped it, it only has MANIFEST.MF inside it 🙈
m
--no-build-cache
maybe?
e
--rerun-tasks
did the trick 🙂 thanks! I will let it build, and try it out after lunch
Ok, can confirm, the fix works well 🙂
m
Nice, thanks for confirming! Will do a patch on Monday