[iuliiasobolevska]

Summary

generateJava can restore stale output from the build cache because schema parse order depends on absolute filesystem paths and ZIP entry order, while its existing file and classpath fingerprints do not capture those ordering differences. The affected output includes generated field and constructor parameter order.

This change gives Gradle an ordered, relocatable schema input manifest with content hashes, then uses that sequence for generation. Filesystem schemas follow configured root order and root-relative path order. Dependency-jar schemas follow entry-name order and a content-derived jar order. A separate ordered manifest keeps dependency type-mapping precedence in the cache key; the mappings themselves still merge in their original input order. The unreleased changelog calls out fresh-output ordering changes.

Validation

• Focused SchemaMergingTest (6/6) and GenerateJavaTaskBuildCacheTest (9/9) passed on JDK 17 with the in-process Kotlin compiler. They cover swapped same-name schema contents, configured root reversal, workspace relocation, jar entry and name order, mapping precedence, and --configuration-cache --configuration-cache-problems=fail reuse.
• :graphql-dgs-codegen-core:formatKotlin, :graphql-dgs-codegen-gradle:formatKotlin, :graphql-dgs-codegen-gradle:validatePlugins, and git diff --check passed.

[jiholee17]

Change makes sense for Gradle caching but with ordering by name it may break existing usages, i.e.

# a-base.graphqls
type Query { foo: Foo }
type Foo { id: String }

# z-legacy.graphqls
extend type Foo { legacy: String }

# b-current.graphqls
extend type Foo { current: String }

where if legacy came before current previously, a constructor taking positional args may switch the positions since b-current.graphqls is written first. Since this is intentional maybe worth a docs update or finding consumers that would break

[iuliiasobolevska]

Good catch. I’ve restored the 8.7.0 behavior: codegen reads schemas in ZIP entry order, so existing field and positional constructor order stays the same. Gradle now includes that schema entry order in generateJava’s cache key, which prevents a stale cache hit when a jar is repacked in a different order. The task remains cacheable and can reuse output when the order matches. Checking the key requires scanning entry names, but a cache hit still skips code generation.

[iuliiasobolevska]

I missed that force-push failed and accidentally merged the PR without the fix - correcting it all in a follow-up #980