I'm using Gradle with the wrapper, and the folder structure by default is like so:

.
├── settings.gradle
├── build.gradle
├── gradle.properties
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat

However, I would like to change it to so:

.
├── gradle
|   ├── build.gradle
│   ├── settings.gradle
│   ├── gradle.properties
│   └── wrapper
│       ├── gradlew
│       ├── gradlew.bat
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
└── src
    ├── main
    └── test

Other than the fact that I don't know how to tell IntelliJ about the folder structure, I don't know how to change it for Gradle since the Environment Options related with changing the folder structure are deprecated:

-b, --build-file (deprecated)

Specifies the build file. For example: gradle --build-file=foo.gradle. The default is build.gradle, then build.gradle.kts.

-c, --settings-file (deprecated)

Specifies the settings file. For example: gradle --settings-file=somewhere/else/settings.gradle

CodePudding user response：

You can't tell Gradle and Intellij IDEA that you use a non-standard Gradle build layout. And in all honesty, you shouldn't even consider that unless you have strong reasons to do so. There are mainly two reasons for that:

• Developers familiar with one Gradle project feel immediately at home when starting with your Gradle project.
• A non-standard build file and directory layout requires additional logic in IDE's (which is not present) and requires to provide extra parameters when building on the command line.

To put things into context, please have look at Gradle issue #16402.

Deprecate command-line options that describe the build layout

The -b and -c command-line options are effectively used to describe a non-standard build layout to Gradle. This is problematic because it means that a specific combination of options must be used whenever Gradle is used on that build, for example whenever invoked from the IDE, CI, command-line or some other tool. These command-line options also have some potentially surprising behaviours, such as running a settings script present in the target directory.

We don't think there are any use cases that are strong enough to justify keeping these options, and we should remove them (via deprecation). If we discover there are some use cases, we might consider replacing the options with more self-describing contracts, for example conventions for build script names.