Avoiding forcing resolution when configuring QuarkusApplicationModelTask

[cdsap]

Issue #43258 describes a problem where a build using a Java platform module and an eager configuration call produces the following error:

Failed to apply plugin 'org.gradle.java-platform'.
> Project#afterEvaluate(Action) on project ':lib' cannot be executed in the current context.

The eager tasks.all will immediately create and configure any registered task. During the configuration of QuarkusApplicationModelTask is required to resolve various configurations, which happens within the lazy action of a task's register configure block, triggering the Quarkus resolution chain(Runtime Configuration → Forced Deployment Resolution → Conditional Helper). Resolving the configuration causes Gradle to configure the lib project, which applies the java-platform plugin. Applying this plugin triggers an afterEvaluate block—a lazy action—resulting in Gradle's restriction that you cannot perform a lazy action within another lazy action.
We were able to reproduce this behavior in Gradle without applying the Quarkus Plugin: https://github.com/cdsap/JavaPlatformIssue

This PR proposes a fix that avoids forcing the resolution in ApplicationDeploymentClasspathBuilder for:

public Configuration getRuntimeConfiguration() {
    this.getDeploymentConfiguration().resolve();
    return project.getConfigurations().getByName(this.runtimeConfigurationName);
}

For the QuarkusApplicationModelTask, we set the required configurations using a new method that removes the forced resolution:

public Configuration getRuntimeConfigurationWithoutResolvingDeployment() {
    return project.getConfigurations().getByName(this.runtimeConfigurationName);
}

This fix addresses the Java platform issue, but as a side effect, it broke conditional dependencies, as we are no longer resolving the configuration, and the Quarkus deployment configuration is not informed about those conditional dependencies. This issue was identified during test executions.

To resolve this, we've created a new input for the model task that uses:

classpath.getDeploymentConfiguration().getIncoming().getFiles()

This allows us to retrieve the FileCollection from the incoming dependencies of the Quarkus deployment configuration without resolving the dependencies immediately.

This PR also adds a new integration test covering the use case of the original issue.

@aloubyansky @gnodet do you have in mind additional eager resolution edge cases I could add to the tests?

[aloubyansky]

@cdsap do I understand correctly that the Quarkus runtime configuration will not include conditional dependencies with this change?

[aloubyansky]

It doesn't include conditional dependencies and somehow it appears to be not a regression.

[aloubyansky]

This method looks the same as the existing getRawRuntimeConfiguration() though

[quarkus-bot]

Status for workflow Quarkus CI

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

✅ 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]

TBH, I'd like to spend more time studying the details but given the CI is green, the new test is passing and I couldn't spot a regression where I thought it could be, I'm ok including it in 3.16.0 that is planned to be released today.