[GRADLE-1249] issues with --daemon and current directory (user.dir system property) Created: 09/Dec/10  Updated: 04/Jan/13  Resolved: 14/Aug/11

Status: Resolved
Project: Gradle
Affects Version/s: 0.9-rc-3
Fix Version/s: 1.0-milestone-2

Type: Bug
Reporter: Lance Hankins Assignee: Szczepan Faber
Resolution: Fixed Votes: 0


 Description   

When I try to use the --daemon feature in the 0.9-rc3 release, the gradle daemon process seems to end up with the wrong working directory. For example, suppose I have my gradle based project checked out here :

/work/project1

I have a bash shell open in that directory, and I run :

gradle --daemon clean

The daemon process starts, but the process has the wrong working directory (it sees the current directory as /home/lhankins/.gradle instead of /work/project1). I have verified this by using VisualVM to attach to the gradle process and inspect the system properties (the user.dir propoerty has a value of /home/lhankins/.gradle instead of the expected /work/project1).

The reason I noticed this is because our build.gradle file tries to load a property file which is located relative to the project directory (./metadata/default.properties). When I run with --daemon, I get a FileNotFoundException when it tries to load this file.

If I skip the --daemon flag, things run fine (we've been using gradle 0.9-rc1 for months).

One other piece of information, if I add the --foreground argument along with --daemon, then things work just fine (inspecting VisualVM, user.dir system property is correctly set to /work/project1).



 Comments   
Comment by Lance Hankins [ 09/Dec/10 ]

One other note. Another way I double checked that the current working directory is wrong with --daemon, was by adding this to our build.gradle file :

File f = new File(".");
println("\n\n\n\tCurrent Dir : " + f.getAbsolutePath() + "\n\n");

Comment by René Gröschke (Inactive) [ 09/Dec/10 ]

Hi Lance,
this isn't a bug I think. In your gradle build scripts, you should refer to files and directories using the file("...") method instead of new File(""). See http://www.gradle.org/latest/docs/javadoc/org/gradle/api/Project.html#file(java.lang.Object) for further informations.
regards,
René

Comment by René Gröschke (Inactive) [ 09/Dec/10 ]

BTW.: You can use groovies metaprogramming features to get "new File(String)" working with the project directory as refernce dir. Adding this to your build file should do the trick:

File.metaClass.constructor =

{ String title -> new File(projectDir.absolutePath, title) }
Comment by Lance Hankins [ 09/Dec/10 ]

Hi Rene,

There is definitely a difference to how those two variants are evaluated, but ONLY when you pass --daemon.

I am fine with the suggested workaround, but this sure seems like a bug to me. Consider this simplified example (excerpt from build.gradle) :

def gf = file(".")
println("Current Working Directory (groovy) : " + gf.getAbsolutePath())

File f = new File(".");
println("  Current Working Directory (java) : " + f.getAbsolutePath());

Given this simple example, lets examine the output when I use 3 different sets of command line options invoking gradle

Case #1

The output if I invoke gradle with the --daemon option, e.g.

gradle --daemon clean

Current Working Directory (groovy) : /work/project1
  Current Working Directory (java) : /home/lhankins/.gradle/.


Case #2

The output if I run normally (WITHOUT --daemon), e.g.

gradle clean

Current Working Directory (groovy) : /work/project1
  Current Working Directory (java) : /work/project1/.


Case #3

The output if I invoke gradle with both --daemon --foreground (in console 1), then invoke gradle clean (from console 2)

(console 1)

gradle --daemon --foreground

(console 2)

gradle --daemon clean

Current Working Directory (groovy) : /work/project1
  Current Working Directory (java) : /work/project1/.


Shouldn't all three of these cases result in the path evaluating consistently...?

Comment by René Gröschke (Inactive) [ 10/Dec/10 ]

That's why you always should use file(".") instead of new File("").
This is the only way to get a consistent reference to a file relative to your project directory.
The jre does not support a manual setup of the working directory I think.
There's a CASE #4:
If you want to run your build files from other directories using the -p option you have to use the file(".") method if you use relative paths in your build file.

Comment by Robert Fischer [ 08/Jan/11 ]

This is a specific case of GRADLE-1296, I think.

Comment by Szczepan Faber [ 11/Aug/11 ]

As mentioned - it's a duplicate of the issue that is already solved.

Comment by Adam Murdoch [ 11/Aug/11 ]

This is not GRADLE-1296. Setting 'user.dir' does not solve the problem. Some things take 'user.dir' into account, but some things do not and use the process' working directory instead.

Comment by Adam Murdoch [ 14/Aug/11 ]

I'll close this again. Added a more specific issue GRADLE-1747.

Generated at Wed Jun 30 11:50:44 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.