Removing cacheability for QuarkusApplicationModelTask

[cdsap]

Following up on issue #47926, we initially attempted to address the problem in PR #48290. However, the CI execution revealed failures in the Conditional Dependencies tests. Upon investigation, we found that the proposed fix was resolving the configuration eagerly—before the Conditional Dependencies logic was applied—thereby breaking the expected functionality.

I explored alternative solutions, such as using QuarkusExtensionView in the model task. This worked partially for the same module but did not handle the case described in the original reproducer, where JARs are manually removed.

The root cause of the issue is that ModelTask hits the cache even when the Quarkus version changes, since the version does not affect the application model's classpath. To address this, this PR proposes disabling the cacheability of the ModelTask. This effectively resolves the main issue reported in the original ticket.

As a follow-up, we could explore more targeted solutions—such as introducing a dedicated input for ModelTask that resolves the configuration during execution and captures the dependency versions.

cc @HerrDerb

[quarkus-bot]

Status for workflow Quarkus CI

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

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

[HerrDerb]

@cdsap @aloubyansky 🚀 Thanks 👍 Is it possible to include this into 3.24.0 already?

[aloubyansky]

@HerrDerb unfortunately, the core artifacts 3.24.0 have already been released. The platform release will be finalized on the 25th. It will be included in the next patch release.