Is it possible to set the process 'cwd' (aka 'working directory') via the tooling API?


(Kris De Volder) #1

There’s a issue in STS/Gradle issue tracker that needs this ability to set the workingdir explicitly to the root project location (or alternatively, the tooling api would itself ensure the working directory is set to root project location).

As far as I can tell, there is no API yet to set the working directory of the deamon process and it simply uses the same directory as the process calling into the tooling API. For the IDE this location is unpredictable and depends on how the user launches the IDE, more importantly, this location typcially has no relation to the project.

STS issue: https://issuetracker.springsource.com/browse/STS-2983


(Luke Daley) #2

What issue does the working directory is not the project dir cause?

Even without using the daemon you should never assume that the JVM working dir is the project dir, as Gradle can be launched from a subproject for example.

This is why you should never use ‘new File(«path»)’ for a project relative path, but should use ‘project.file(«path»)’.

This is something we could fix through JNA, and probably will at some point, but understanding your exact problem will help with prioritisation.


(Kris De Volder) #3

What issue does the working directory is not the project dir cause?

See the issue I pointed to. Users will observe different behavior between commandline and IDE if they use 'new File(…relative path…)

This is why you should never use new File(«path») for a project relative path, but should use project.file(«path»).

I certainly agree with you that this is inadvisible and there are good ways to avoid doing it this way.

At the same time, it still makes sense to strive for the commandline tools and IDE tools to behave the same way as much as is possible / reasonable.

As to how important this is, I would say relatively minor giving that it addresses an issue that can easily be avoided and is caused by doing something that is really ill-advised in the first place.

Also I believe that, just like commandline arguments, environment parameters and system properties, the ‘cwd’ is really a contextual parameter that a user might reasonably expect to have control over when they specify how to launch a gradle process.


(Luke Daley) #4

Points noted, thanks. I’ll bring this to Szczepan’s attention.

At the same time, it still makes sense to strive for the commandline tools and IDE tools to behave the same way as much as is possible / reasonable.

The thing here though is that we don’t guarantee the cwd when invoking via the command line. If you’re using the daemon from the command line then the working directory may not be the project directory. Or even if you’re executing from a subproject.


(Szczepan Faber) #5

I agree with Kris, this is a missing capability of the Tooling API. I would expect this to be configurable, just like the env vars (even though we don’t like them). Exporting to jira…


(Kris De Volder) #6

The thing here though is that we don’t guarantee the cwd when invoking via the command line.

I figured as much, but practically speaking I guess the typical thing to do is to run something like ‘./gradlew …command…’ from the root project location. So this the behavior most users will see and therfore expect also from the IDE.

Not trying to say we should definitely act on this. Just following up on an issue one user raised on our issue tracker and this is exactly that users expectation. When explained that he probably shouldn’t use 'new File(…relative path…) he seems to agree. I’d be happy to close that issue as ‘Works as Designed’ but just wanted to follow up a little bit with you guys first.

I think whether or not we do something to ‘fix’ this issue depends on how much work it is. If its a really easy fix… I’d say we should do something about it. If its rather complicated, its not important enough to fix.


(Kris De Volder) #7

Link to the jira issue?


(Kris De Volder) #8

Another Gradle-STS user has hit a similar problem: https://issuetracker.springsource.com/browse/STS-3142


(Luke Daley) #9

GRADLE-2532