gradlephant Struggle with Gradle and want it to get better? We need your help! At Gradle, we are committed to enhancing developer experience, and user feedback is crucial in helping us prioritize our efforts. From deep topic dives to "If you could change one thing in Gradle to improve your experience with it, what would this change be?", all feedback would be useful to prioritize our development, documentation and advocacy efforts. Take the developer survey here: https://gradle.org/2024-developer-survey P.S: Those who provide the most insightful responses will receive special edition Gradle swag or gift cards, we are working on the details

Is there a deadline for the survey? Just want to know so I can tell my team.

Hi! We plan to keep it running for a few months, but we'll be looking at the results regularly and adjusting content and plans based on the results. So earlier the merrier, but it will be always appreciated 🙂

I completed the survey yesterday, then inevitably thought of my two most significant bits of feedback... 1) Gradle is noisy. At the root my project contains 8 Gradle specific directories or files, which seems... excessive: a. .gradle/ b. build/ c. gradle/ d. build.gradle.kts e. gradle.properties f. gradlew g. gradlew.bat h. settings.gradle.kts 2) Gradle has a confusing array of cache & output directories, some of them prefixed with the gradle version, but not nested in a way that allows easy distinguishing between them by path: a. .gradle/ b. build/ c. $HOME/.gradle/caches/build-cache-1 d. $HOME/.gradle/caches/jars-2 e. $HOME/.gradle/caches/jars-3 f. $HOME/.gradle/caches/jars-4 g. $HOME/.gradle/caches/journal-1 h. $HOME/.gradle/caches/modules-2 i. $HOME/.gradle/caches/transforms-2 j. $HOME/.gradle/caches/8.8/ k. $HOME/.gradle/caches/8.9/ This makes Gradle projects confusing to build efficiently inside a multi-stage Dockerfile. It is very hard to work out how to combine image layer caching (for things that seldom change - Gradle binaries, dependencies) with

RUN --mount=type=cache

for more ephemeral caches (configuration cache, incremental compilation) in a way that will allow Docker / buildx to get cache hits as often as possible. Perhaps one should abandon layer caching entirely and solely use

RUN --mount=type=cache,target=$HOME/.gradle

? Or does that cache expire more regularly than layer caching? Should one also use

RUN --mount=type=cache,target=.gradle

? Who knows? What about

RUN --mount=type=cache,target=build

? A change to a more nested structure would at least allow easier path based management, without having to change the Dockerfile when you upgrade Gradle:

$HOME/.gradle/caches
├── dependencies
│   ├── jars
│   │   ├── 2
│   │   ├── 3
│   │   └── 4
│   └── modules
│       └── 2
├── gradle_versions
│   └── 8.10
│       ├── file-changes
│       ├── fileContent
│       └── etc
└── other
    ├── build-cache
    │   └── 1
    ├── journal
    │   └── 1
    └── transforms
        ├── 2
        ├── 3
        └── 4

Hi @Robert Elliot, thanks a lot for extra feedback! This channel works for the content. I also created a quick form for additional quick feedback: https://forms.gle/v8ZNNJnuQo6qnPVo6