Extracting baseconfig inputs from extensionview

[cdsap]

Issue #48651 describes a build failure when executing the classes task:

Some problems were found with the configuration of task ':project:quarkusGenerateCodeDev' (type 'QuarkusGenerateCode').

- In plugin 'io.quarkus' type 'io.quarkus.gradle.tasks.QuarkusGenerateCode' property 'applicationModel' doesn't have a configured value.

  Reason: This property isn't marked as optional and no value has been configured.

  Possible solutions:
    1. Assign a value to 'applicationModel'.
    2. Mark property 'applicationModel' as optional.

  For more information, please refer to https://docs.gradle.org/8.14.2/userguide/validation_problems.html#value_not_set

- In plugin 'io.quarkus' type 'io.quarkus.gradle.tasks.QuarkusGenerateCode' property 'classpath' doesn't have a configured value.

  Reason: This property isn't marked as optional and no value has been configured.

  Possible solutions:
    1. Assign a value to 'classpath'.
    2. Mark property 'classpath' as optional.

Initially, the failure didn’t make much sense because there is a known relationship between the ApplicationModel task and the generated tasks. Something was breaking the task dependency hierarchy.

Investigation Summary

We observed:

• The issue did not occur when executing assemble, build, or other typical Quarkus tasks.

• It could be reproduced in Quarkus projects if the extension configuration triggered eager task resolution, for example:

quarkus {
  quarkusBuildProperties.putAll(
    provider {
      tasks
        .named("jar", Jar::class.java)
        .get() // <- eager resolution
        .manifest
        .attributes
        .map { e -> "quarkus.package.jar.manifest.attributes.\"${e.key}\"" to e.value.toString() }
        .toMap()
    }
  )
}

In contrast, replacing .get() with .flatMap avoided the resolution but did not fix the issue on the client side.

User reports confirm the issue occurs on Quarkus 3.23.1 but not in 3.23.0, although we could not directly link the behavior to the project descriptor rework.

We also verified that in a non-Quarkus project, we could not reproduce the issue using the same structure as the Quarkus plugin. Even with eager resolution in place, task dependencies were respected as expected.

Root Cause

Deeper investigation revealed that the issue was triggered by the initialization of QuarkusPluginExtensionView, specifically due to inputs that rely on the instantiation of the BaseConfig object:

getCachingRelevantInput()
    .set(extension.baseConfig().cachingRelevantProperties(extension.getCachingRelevantProperties().get()));

It’s unclear why this initialization disrupts the task graph, but it causes a failure when tasks like classes are executed in isolation.

Fix Summary (this PR)

• Extracted inputs requiring BaseConfig from QuarkusPluginExtensionView.

• Decoupled inputs specific to QuarkusBuildTask and moved them out of the shared extension view, keeping only common inputs.

• Introduced a new base task class to hold common inputs and QuarkusPluginExtensionView.

• Inputs depending on baseConfig are now set during task configuration time (not during extension instantiation).

• Added a new EffectiveConfigProvider in the base task to abstract effective configuration.

• Added a regression test to cover the issue reported.

Motivation

Given the unexpected side effects caused by the early instantiation of BaseConfig inside the extension, especially since it is injected into both QuarkusGenerateCode and QuarkusBuildTask, we chose to restructure the task input declaration.

Previously, QuarkusPluginExtensionView held all inputs for both tasks, including those not required for QuarkusGenerateCode. We split these inputs into their respective tasks and delegated common ones to a shared base task.

This change ensures that only the required inputs are declared eagerly, and those dependent on BaseConfig are delayed until configuration time, improving configuration cache compatibility and fixing the task failure issue.

CI checks

https://github.com/cdsap/quarkus/actions/runs/16061544644

• Fixes: Gradle plugin: task "classes" fails with "property 'xyz' doesn't have a configured value" #48651

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit bba66c1.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[aloubyansky]

Thanks @cdsap !