[GRADLE-604] An issue with combining --project-dir and --settings-file or --build-file options Created: 24/Aug/09 Updated: 10/Feb/17 Resolved: 10/Feb/17
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)
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.
|Comment by Benjamin Muschko [ 15/Nov/16 ]|
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]|
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.