close
Skip to content

Make GenerateJavaTask.schemaPaths lazy instead of @Input List<Any> (fixes #952) - #956

Open
harshit6392 wants to merge 1 commit into
Netflix:masterfrom
harshit6392:fix/lazy-schema-paths
Open

Make GenerateJavaTask.schemaPaths lazy instead of @Input List<Any> (fixes #952)#956
harshit6392 wants to merge 1 commit into
Netflix:masterfrom
harshit6392:fix/lazy-schema-paths

Conversation

@harshit6392

Copy link
Copy Markdown

Fixes #952

What changed

GenerateJavaTask.schemaPaths was a plain var schemaPaths = mutableListOf<Any>(...) annotated
@InputFiles. This PR changes it to a proper ConfigurableFileCollection, mirroring how
dgsCodegenClasspath is already declared in the same class:

  • schemaPaths is now a val schemaPaths: ConfigurableFileCollection, annotated with
    @get:InputFiles and @get:PathSensitive(PathSensitivity.RELATIVE).
  • Three setSchemaPaths overloads are added — accepting Iterable<Any>, Provider<out Iterable<Any>>,
    and FileCollection — all delegating to schemaPaths.setFrom(...).
  • generate() now resolves schemaPaths.files lazily at task-execution time instead of eagerly
    mapping the old List<Any> via Paths.get(it.toString()).

Why

  • Laziness: the old field was a plain configuration-time value, so any input coming from a
    Provider (e.g. a schema location resolved from an external dependency/configuration) had to be
    resolved at configuration time — exactly what Gradle's lazy configuration model is meant to avoid.
  • Correct up-to-date checking: List<Any> of raw strings doesn't give Gradle proper
    content-based snapshotting. ConfigurableFileCollection + @PathSensitive(RELATIVE) brings
    schemaPaths in line with how dgsCodegenClasspath is already handled, so Gradle can correctly
    determine task avoidance.
  • Type safety: with List<Any>, passing something like a Set<File> as a single list element
    silently stringified into [/path/to/schema.graphqls] (brackets included), only surfacing as a
    downstream compilation failure. A FileCollection-backed property can't be misused this way.

Backward compatibility

Existing build scripts using schemaPaths = ["${projectDir}/src/main/resources/schema"] continue to
work unchanged — in Groovy, schemaPaths = [...] resolves to a call to setSchemaPaths(Iterable<Any>),
one of the added overloads. No existing build.gradle files in this repo's test fixtures needed
changes.

In addition to the existing string-list form, schemaPaths can now also be set to a FileCollection
or a Provider<Iterable<Any>>, e.g.:

schemaPaths.setFrom(someExternalConfiguration.map { it.files })

Testing

  • Existing Gradle functional tests (CodegenGradlePluginTest, CodegenGradlePluginSpringBootSmokeTest,
    CodegenGradlePluginEntitySmokeTest) continue to exercise the string-list schemaPaths = [...] form
    used across all test-project fixtures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make GenerateJavaTask.schemaPaths lazy instead of @Input List<Any>

1 participant