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.
--
John Murph
Automated Logic Research Team
