[GRADLE-2532] make it possible to configure the working dir via the tooling API Created: 23/Oct/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 2


 Description   

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

Workaround

Gradle users are kindly asked to write build logic that does not depend on the current working dir. For example, instead of new File("foo.txt") please write project.file("foo.txt").



 Comments   
Comment by Gradle Forums [ 23/Oct/12 ]

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.

Comment by Gradle Forums [ 23/Oct/12 ]

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

Comment by Gradle Forums [ 23/Oct/12 ]

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.

Comment by Gradle Forums [ 23/Oct/12 ]

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

Comment by Gus Heck [ 23/Apr/14 ]

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

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 10/Feb/17 ]

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.

Generated at Wed Jun 30 12:24:31 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.