On Aug 17, 2009, at 7:48 PM, 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.
Could you file a Jira for this with the content of your posting?
Thanks
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
