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 that for years for JDT, WTP, STS projects), but these absolute paths prevent that. Is there any way they could be eliminated so gradle.prefs can be shared across workspaces?
2 Likes
Hi Eric
These paths point to the physical location of the project on the user’s machine since this is where Gradle is invoked during project import, task execution, etc. What would the paths be relative to?
So far, we did not design this prefs file to be shared across users. It is an artifact produced during the import. The project can still be shared across users by sharing the .project files.
Etienne
When sharing Eclipse projects, my goal is to make the process of going from “empty workspace” to running app in as few steps as possible. I’ve managed to accomplish this (many times) by carefully configuring projects to avoid any workspace-specific settings (like using Execution Environments on project build path as opposed to specific JRE libraries, etc). I also avoid things like mvn eclipse:eclipse and gradlew eclipse because they don’t do a good job of supporting this scenario (in fact, they necessarily make the whole process into multiple steps since they require first checking out, then running mvn/gradle). Since this is my first time using Buildship, I’m just learning how it integrates.
If I understand correctly, Buildship as it currently stands, requires the Import wizard to properly detect and import the projects. I would love to be able to use a Team Project Set or just manually point them to the SCM repository and do the import that way, without much (any) user interaction. I’m guessing that’s not on the Buildship radar, is it?
1 Like
To be more specific:
What I’ve discovered happens is if gradle.prefs isn’t checked in, and I import the project directly from checkout (not using the Buildship import wizard), which is how I have to do it for git, for example, then Buildship produces an error marker on the project. It looks like what happens is Buildship recognizes the Eclipse .project but does not automatically create a gradle.prefs file.
Other plugins handle this gacefully because I can check in their config files (eg, JDT’s .classpath file) that are immediately recognized no matter how the project is brought into Eclipse.
First of all, thanks for your detailed feedback! We intend to be part of the new ‘global import’ feature (not the official name) that is planned to be part of the Eclipse Neon core. It will contain auto-detection of project types. RedHat is working on this feature and they had already contacted us so we can also be part of the recognized project types. It will simplify the project setup some more. I believe all you will need to do is point to the vcs location.
Yes. We currently don’t do this since it has not been obvious to us how we can derive the prefs files’ content if all we have is a project. We can look deeper into this but it would currently not be high on the list.
What info is needed that can’t be retrieved from the IProject?
Alternatively, how about invoking the import wizard UI upon detection of an Eclipse Project (the .project file) without a corresponding gradle.prefs?
- the root project the project belongs to
- what configuration it was imported with (Gradle distribution, etc.).
A different use-case - similar symptoms:
I have eclipse set up both at home and at work.
From work, I access it as /home/pmorch/work/java, and from home it is /home/peter/work/java.
In both cases an sshfs mount. Now I’m forced to have the same absolute path in both cases, which means it can’t be in my $HOME dir.
That seems like an unnecessary limitation for me.
And not only that… Also symlinks aren’t honored. So if I e.g.
sudo ln -s /home/$LOGNAME/work/java /workJava
And import the project from /workJava, then the settings in .classpath and .settings/gradle.prefs still refer to /home/$LOGNAME/work/java and not to /workJava. And this breaks when $LOGNAME differs between machines.
Bummer… 
Are there any news on this? The saved directory is ever one level higher as the gradle.prefs file. This make no sense for me.
This is the larges problem to switch from springsource to buildship.
No news. We will look into this, considering that this has been requested several times.
I assume you are referring to ‘connection_project_dir’. This is the root project of the imported Gradle project. Depending on the project layout, this is not always one level higher.
I’m very interested in this features and would consider implementing it among others on the 1.0.x codebase. I’ve installed the 1.0.6.v20151110 snapshot to make sure I’m not stating anything that is already implemented and these are the features I’d like to implement:
- Make gradle.prefs file not require absolute paths. The gradle.prefs file should be able to be checked into a repository and checked out by another user without causing issues due to absolute paths.
- If no gradle.prefs file found but buildship nature is present, trigger the import dialog to start so the user can select gradle version and cache location.
- Add workspace level preference UI for configuring gradle version and cache location for all new projects if no gradle.prefs file found.
- Add project level preferences for editing the cache location and gradle version to use for a specific project.
- Add ability to create different gradle libraries for the project using different dependency configurations much like the ivy plugin supports. This is more useful for war producing projects but that way I can create two libraries, one for packaged dependencies in my war and one for test/compile time only dependencies. Then I can configure my deployed resources for my project to only deploy the packaged dependencies so I can reflect a generated war when deploying to a server within Eclipse.
Let me know what you think.
2 Likes
As a user, those ideas all sound excellent. Having those features would definitely make the tool feel more mature and robust.
Hi Max,
The ideas you enumerate are certainly interesting and most of them were already requested by other users on this forum and/or in Bugzilla. The project is open for contributions and it’s nice to hear that you are interested in implementing new features.
Contributing into Buildship is done via pull requests. Please note that we carefully consider every changes before merging them to the codebase. To make this process efficient we’d need an explanation (a.k.a a story) what do you want to add, how an implementation would look like and what are the test cases. An example for such story can be found here. If you provide a story before the implementation we can give you an early feedback if it fits into the existing design.
If you need further or you have question about the project internals just let us know. Also, if you want to get started with the codebase then check the development setup instructions.
This would save us a lot of headache if this was fixed.
Everyone in our project has to edit gradle.prefs for each project that they retrieve from our SVN source control.
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 simply checkout the code and start working, as the absolute varies between developers.
Ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=470946
1 Like
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 ensure that none your changes are not in vain.
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?