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.

> 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.

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.

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...

This would be helpful since some plugins wrap code that reads non-gradle configuration and tries to load files based on information in those files and thus they assume the CWD. One specific example is the Liquibase plugin. There is no way for a gradle user to code around this other than to not use the plugin. This causes builds that work on command line, but not in IDE's for example... http://youtrack.jetbrains.com/issue/IDEA-118062

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.