Here is confirmation that gradle.properties is in my root project directory:
$ ls -al
total 56
drwxr-xr-x
12 petrovic
CORP\Domain Users
408 Dec
6 14:12 .
drwxr-xr-x
21 petrovic
CORP\Domain Users
714 Dec
6 10:49 ..
drwxr-xr-x
4 petrovic
CORP\Domain Users
136 Dec
6 13:12 .gradle
drwxr-xr-x
14 petrovic
CORP\Domain Users
476 Dec
6 14:02 .idea
drwxr-xr-x
8 petrovic
CORP\Domain Users
272 Dec
6 13:57 build
-rw-r--r--@
1 petrovic
CORP\Domain Users
323 Dec
6 11:32 build.gradle
drwxr-xr-x
3 petrovic
CORP\Domain Users
102 Dec
6 13:55 gradle
-rw-r--r--
1 petrovic
CORP\Domain Users
23 Dec
6 14:12 gradle.properties
-rwxr-xr-x
1 petrovic
CORP\Domain Users
5080 Dec
6 13:55 gradlew
-rw-r--r--
1 petrovic
CORP\Domain Users
2404 Dec
6 13:55 gradlew.bat
-rw-r--r--
1 petrovic
CORP\Domain Users
978 Dec
6 13:58 reflection-lab.iml
drwxr-xr-x
4 petrovic
CORP\Domain Users
136 Dec
6 10:49 src
Here are two different representations of my gradle.properties file showing no special characters (I checked the hex output character by character):
$ hexdump -C gradle.properties
00000000
6f 72 67 2e 67 72 61 64
6c 65 2e 64 61 65 6d 6f
|org.gradle.daemo|
00000010
6e 3d 74 72 75 65 0a
|n=true.|
00000017
$ hexdump -c gradle.properties
0000000
o
r
g
.
g
r
a
d
l
e
.
d
a
e
m
o
0000010
n
=
t
r
u
e
\n
0000017
Running with export GRADLE_OPTS=-Dorg.gradle.daemon=true results in the daemon being used.
But I think I have a dim idea of what is going on. I hope this is not a red herring, so hold on tight…
The project directory I am working in is one I consider a standalone project - it’s a one-off spike project. It has no parent, as in multiproject. But three levels directly up there exists an unrelated build.gradle and settings.gradle file (that does not refer to the project that is the subject of this thread). However, one level directly up from this thread’s project there exist no gradle related files. This configuration of directories does not end up using a running daemon.
Next: move this thread’s project to a directory that contains no parent that contains any file related to gradle. Now when I build, the daemon is used.
I have some dtruss output on the Mac that shows a lot more gradle files being found higher in the path for the first case vs. the second (a condition which I explicitly arranged for, given what I said in the preceding two paragraphs). I don’t show that here, but I can post it later if it matters. (sudo dtruss -f x.sh # where x.sh contains “gradle build”).
It appears to me that gradle in the first case is walking up the file system and finding files that are not logically related to this thread’s build, and somehow using the file content or the existence of those files to influence this thread’s build.
That file is settings.gradle three levels up, which does not reference this thread’s project. That file contains an ‘include’ statement that references other subprojects. (Eventually I will clean this up and not have gradle files directly up from where I am. I think. No matter.) If I remove that settings.gradle file, then both configurations use the daemon.
Whew. So gradle is allowing files several levels (with gradle-config-voids at intervening levels) up to influence this build.