For our project, we have a custom .bat and .sh that set these options and pass-through to the gradle .bat or .sh files. This makes it easier to use Gradle from the command line for our project (as it is currently defined). However, if I do this right now I get an interesting problem. Here is our layout (generically)

<root dir>
custom gradle.bat and gradle.sh
<root of projects>
<project 1> (build.gradle in this directory)
...
<project n> (build.gradle in this directory)
<buildSrc project>
root.gradle (this is the "main" build.gradle for the whole project)
settings.gradle

I agree it's a bit weird, but it has to do with IDEA modules and content roots and stuff. So, what we have is a .bat (for example) in <root dir> that does

call <path-to-gradle>\gradle.bat --project-dir <root of projects> --settings-dir <root of projects>\<buildSrc project>\settings.gradle %*

And then settings.gradle just sets the root project descriptors buildFileName to be '<buildSrc project>/root.gradle'.

Problem is, this doesn't work. My recent changes to make buildSrc be built before settings is run fails, because that code assumes it will find the buildSrc directory under the directory where settings.gradle is located. So, I thought I had found a bug (after all, I am explicitly setting the project dir, shouldn't it use that?). So, I made a test case and went to fix it. That's when I found that other things seem to expect this weird behavior.

Let's talk about my "fix". StartParameters has three methods that change the currentDir: setBuildFile(), setSettingsFile(), and setProjectDir(). The order in which these are called matters, because they all reset currentDir without condition. So, I thought I should remember if setProjectDir() has been called and not reset currentDir from the other two methods if it has been. The idea being that setProjectDir()'s explicit purpose it to set that parameter, whereas the others do it as more of a side effect. That still leaves setBuildFile() and setSettingsFile() being order-dependant, but it would solve my immediate needs, so I started down that path.

Unfortunately, that makes ProjectLoadingIntegrationTest#buildFailsWhenSpecifiedSettingsFileDoesNotContainMatchingProject() start failing. This test, it turns out, is built around the idea that calling setSettingsFile() will change current dir out from under the setProjectDir() call. This seemed like a mistaken test case, so I started thinking about how to fix it. Unfortunately, I cannot. This is because of the current logic in SettingsHandler that finds the settings.gradle file. The logic is that if the found settings.gradle does not include the current project, then use an empty settings.gradle file, which will ALWAYS include the current project. Unless you do this weird thing that the test case does (which is possible since DefaultCommandLine2StartParameterConverter calls setProjectDir() before calling setSettingsFile()).

So, what should be done here? Do we want the current behavior, or should --project-dir be honored even if --build-file or --settings-file are used? Assuming we want --project-dir to be honored (which is my opinion), what do we do with this test? I think several others have similar issues, but I have not really investigated them (just say them show up as integration test failures after I made my changes). I hate deleting a test, but I just don't know how to legitimately make it fail if --project-dir is honored.