A simple solution to this problem (conceptually, at least) would be to
get rid of the settings file. Then the problem goes away.
Any chance you could live with a workaround like moving the settings
file to <root of projects> temporarily?
John Murph wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
