Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle quarkusGenerateCode runs far too often #41404

Closed
FWest98 opened this issue Jun 24, 2024 · 2 comments · Fixed by #41428
Closed

Gradle quarkusGenerateCode runs far too often #41404

FWest98 opened this issue Jun 24, 2024 · 2 comments · Fixed by #41428
Labels
area/gradle Gradle kind/bug Something isn't working
Milestone

Comments

@FWest98
Copy link
Contributor

FWest98 commented Jun 24, 2024

Describe the bug

When using Gradle to build a Quarkus app, the quarkusGenerateCode task is almost never cached. Even on successive runs of the same codebase without any code changed, this job will rerun - even on codebases where no code is actually being generated.

I managed to boil it down to the following:

  • The task is using cache only when rerunning the exact same configuration; even just running a different unit test (by clicking the gutter in IntelliJ) will cause a rerun.
  • Gradle reports that

    Task ':manager:quarkusGenerateCode' is not up-to-date because:
    Value of input property 'cachingRelevantInput' has changed for task ':manager:quarkusGenerateCode'

  • When digging into what happens here, I found that both the cachingRelevantInput and internalTaskConfig are often found to be "changed". These values are provided by the task here. These values are provided as a normal map.
  • Gradle does not perform a "clever" comparison on these objects (source - the equals call does map-specific things, but will consider map entries as a list and not as a set). In particular, a map with a different order but the same elements is not considered to be equal. Therefore, any change in the order of variables is considered to be a change necessitating a rerun of the job.
    image
  • Gradle seems to be aware of this and and reports "Other pitfalls can be the use of HashMaps or other data structures without order guarantees in the task’s code." (source) as a potential cause for cache invalidation.

So I think on the Quarkus side, it is best to move to a map implementation that guarantees order of some kind - or find some other way to convince Gradle the task can reuse the cached result. In addition, I feel like the scope of the cachingRelevantInput map is too large: it includes all system properties prefixed by quarkus., even those not affecting code generation at all. It might be good to look into reducing this scope as well.

Output of uname -a or ver

Linux FLORIS-NORTH 4.4.0-22621-Microsoft #3672-Microsoft Fri Jan 01 08:00:00 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "17.0.10" 2024-01-16

Quarkus version or git rev

3.11

Build tool (ie. output of mvnw --version or gradlew --version)

8.8

@FWest98 FWest98 added the kind/bug Something isn't working label Jun 24, 2024
@quarkus-bot quarkus-bot bot added the area/gradle Gradle label Jun 24, 2024
@quarkus-bot
Copy link

quarkus-bot bot commented Jun 24, 2024

/cc @glefloch, @quarkusio/devtools

@dmlloyd
Copy link
Member

dmlloyd commented Jun 25, 2024

I have a possible fix in #41428, could you give it a try?

@quarkus-bot quarkus-bot bot added this to the 3.13 - main milestone Jun 26, 2024
@gsmet gsmet modified the milestones: 3.13 - main, 3.12.1 Jun 26, 2024
gsmet pushed a commit to gsmet/quarkus that referenced this issue Jun 26, 2024
holly-cummins pushed a commit to holly-cummins/quarkus that referenced this issue Jul 31, 2024
danielsoro pushed a commit to danielsoro/quarkus that referenced this issue Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/gradle Gradle kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants