So I was tinkering a few weeks back and this is what I did to try and remove the storage of the absolute paths of the project dir stored in the gradle.prefs file as project_dir and connection_project_dir.
Changed class ProjectConfigurationPersistence.
Deleted static preference names for connection_project_dir and project_dir
Removed adding anything related to the project’s location in the saveProjectConfiguration method.
In readProjectConfiguration, right before returning the configuration I got the project directory as a File using: File projectDir = workspaceProject.getLocation().toFile(); and alway use projectDir for FixedRequestAttributres constructor where connection_project_dir config value was used before as well as passing in to ProjectConfiguration.from(…) where project_dir configu value was used before.
That was the extent of what I’ve looked into on my own. I’m not 100% certain why there was two config variables for project directory. Is there a case where they may be different that I’m unaware of?
Ah ok, so the idea is you could potentially have a 3 project setup where one houses the gradle build files (build.gradle, gradle.properties, gradle wrapper, etc), one has the actual source code to build, and another is the eclipse configured project for the build (the one with the gradle.prefs file)? In that case, I’ll add back in the properties to the gradle.prefs but do the following:
If the path is absolute, use it as an absolute path
If the path is not absolute, first check for a project in the workspace with the same name
If not a project in workspace, check new File(path).
Throw error if not found in any of these places.
The tricky part will be serializing the preferences back out the way they were read in to avoid resaving with absolute paths. We will probably need to retain the original preference values in the ProjectConfiguration as well as the actual parsed objects used.
I think the same should apply for the gradle cache setting as well. Except check if path is absolute, if so, use it. If not, use as relative to current workspace. I can also update the import UI to indicate that will be the case.
For the jdk, I’d also like to do something similar, if absolute path, use it. Otherwise check for a jdk defined in the workspace with the name, otherwise throw error or maybe even try to see if there is a jdk associated with the project and use it and ignore the property since it can’t be resolved (and have the validator put out a warning on it) if not jdk on project, check if there is a default jdk defined in the workspace and use it.
If this is all acceptable, I will begin the process of creating a story and getting a pull request generated this weekend. Let me know. Also, I need some information on the project_path config setting. How does it differ to project_dir in it’s use?
In fact there are multiple ways how to solve this problem. We’ll have some internal discussions what should be done. I’ll get back to you in a few days with the details. Nevertheless, we really appreciate that you’d like to help!
As a first step I’d invite you to clone the Buildship repository and submit a pull request with the summary of the first story added to the Project.md file.
In the spec, please include the following steps:
motivation
the proposed changes
an implementation plan
test cases
open questions
This document will serve as a platform to discuss what and how should be done. It doesn’t have to be super precise, just throw your ideas in and we’ll give you feedback.
I just want to make sure the original intent behind this topic is covered by those goals: to be able to check out a Gradle project from SCM and have Buildship know inherently how to handle it without requiring manual triggering by the user. This is how JDT, Spring, m2e, etc projects work.
Ideally it would be best of there no prompting of the user at all (ie, whatever configuration is needed can be done once and checked in to SCM, like the .project and .classpath files).
I lead a product with about 130 projects in it. We’re considering moving to Gradle – I already started the conversion when I ran into this issue. Having engineers manually tweak things every time they import is a non-starter for us.
I have 130+ projects to import. Specifying the preferences for each one isn’t acceptable. Import of projects needs to be a clean operation as it is for Maven and other build tools.
Hi, we are in much the same position as artkauf, erizzo and others with this issue.
We have a large number of projects configured for gradle, and we have developers who retrieve these projects from source control. It simply isn’t feasible for us to have each developer run the Import Wizard for each of these projects after checking them out from SVN.
If the gradle.prefs supported relative paths, we would be able to check out the projects without a manual step involved for each one.
The files that plugins add or alter in the .settings folder are not supposed to have absolute paths. A project’s configuration needs to be workstation independent to work in a team environment. Other plugins do not put absolute paths in .settings for this reason. The paths should be project-relative, workspace-relative, or possibly be based on an Eclipse variable.
What might be a workaround under windows os is using subst.
subst is mouting a path to a virtual drive.
This worked for me when i run into tis issue.
Lets assume you have your workspace in D:\test_buildship\workspace
Than you can do subst w: D:\test_buildship\ and you will have w:\workspace
This cmd is creating a virtual drive per user so it works with different user on the same maschne as well.
If all member of a developer team use the same subst destination path they can use the folder they want but all have the same setup and you can share the projects,