I’ve noticed that the gradle.prefs file is generated with absolute paths (specifically, the prefs named “project.dir” and “connection_project.dir”). In general, the stuff in .settings is free from machine-specific or workspace-specific stuff so it can be checked in to source control (I’ve been doing…

Just an FYI, I’m still looking into to implementing these features and am currently trying to get permission to do it from my employer.

I’ve updated the Bugzilla ticket where this specific issue was discussed, with some code that fixes the issue and allows the use of a ${projectFolder} placeholder that is replaced with the workspace project’s home folder. Until this is resolved, we won’t use buildship since team members can’t simpl…

Hi Max! In case you get the permission I would propose the following: Before you start working on the implementation, do a little analysis on what you plan to change and write a short summary under this forum entry. Then, we will give you feedback if it fits to the existing codebase. This would ensu…

Will do. Tonight I’ll post an outline of some of the changes I already played around with to make the gradle.prefs file more portable. I will need some info though. Why is there a project_dir and connection_project_dir. Is there any use case where they they would be different from each other?

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 connectio…

Here is the difference: project_dir: the directory where the Eclipse project is located. Corresponds to a module in a Gradle build. connection_project_dir: the root folder of the Gradle build. This is what is needed for the import and what is passed to the Tooling API .

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

Max, We had discussion and came to the conclusion the issue should be tackled by implementing the following stories: Move the import preferences (gradle.prefs) to the workspace metadata Open the import dialog if the import preferences are not available Implement legacy Buildship artifact clean-up…

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 i…

Gradle.prefs contains absolute paths

Help/Discuss Buildship

st_oehme (Stefan Oehme) February 24, 2016, 4:34pm 34

Just a quick heads-up: This issue will be resolved as part of Buildship 1.0.10, which we plan to release soon.

Topic		Replies	Views
Rational Team Concert Integration issues with Buildship Buildship issue-resolved	28	4571	April 12, 2016
2.0 release removed gradle options? Buildship buildship	14	2369	March 9, 2018
Buildship plugin does not import project correctly Buildship	16	11856	April 25, 2016
Documentation of org.eclipse.buildship.core.prefs Buildship	7	6646	July 28, 2016
Problem while importing gradle projects into eclipse via "buildship" plugin Help/Discuss buildship , eclipse	1	2527	November 26, 2018

Gradle.prefs contains absolute paths

Related topics