Defining a Property to Resolve Conditional Dependencies in Gradle builds

[cdsap]

The configuration cache compatibility proposal aimed to avoid resolving dependencies during execution while ensuring no incompatible types were introduced. However, the initial PRs revealed failing tests related to ConditionalDependencies. To address this issue, we implemented eager resolution of the deployment configuration to support the required logic for this feature.

While this approach worked, as noted in issue #44940, it introduced an overhead in configuration time for medium-to-large projects.

I evaluated alternative approaches, but resolving the deployment configuration is necessary to handle the conditional dependencies logic. Since the reproducer for the original issue did not implement conditional dependencies, I propose this PR. It introduces logic in the Quarkus Extension to check whether a project uses conditional dependencies. If no conditional dependencies are present, we skip the eager resolution, reducing unnecessary overhead.

My assumption is that most projects do not use conditional dependencies, making this the optimal approach. However, if you believe the logic should be inverted or prefer that a Quarkus build property be used to control this behavior, please let me know.

Tests
#44940 Reproducer, configuration time first build(build): 14s https://ge.solutions-team.gradle.com/s/golwhimdl5sby/performance/configuration
#44940 Reproducer, configuration time second build(build): 3s https://ge.solutions-team.gradle.com/s/owqbjbbdvhz6u/performance/configuration
#44940 Reproducer, configuration time first build, quarkusBuild with configuration cache: 42s https://ge.solutions-team.gradle.com/s/hmzeglndpvh7u/performance/configuration
#44940 Reproducer, configuration time second build, quarkusBuild with configuration cache: 1.9s https://ge.solutions-team.gradle.com/s/l72l75e575eea/performance/configuration

[gsmet]

I'm a bit puzzled by this operation taking so much time. What's going on exactly?

[cdsap]

There is significant configuration resolution across the various configurations created in different modes. This issue is further aggravated when conditional dependencies trigger additional resolution. This PR was just a workaround to disable the resolution. I am closing this PR and will dedicate more time to explore a more elegant solution.