Support .settings folders as linked resources

[sthdev]

It would be nice if Tycho would support .settings folders that are included as a linked resource in a project instead of a physical folder.

Background:

Our repositories are structured like this:

• .settings
• my.org.bundle
• my.org.bundle.test
• my.org.feature

The .settings folder is stored at the root of the repository in order to have on location for the settings of all projects. The individual projects do not have an own .settings folder but include the root .settings folder as a linked resource.

Linked resources are stored in the .project file of a project like this:

<projectDescription>
  <!-- other stuff -->
  <linkedResources>
    <link>
      <name>.settings</name>
      <type>2</type>
      <locationURI>$%7BPARENT-1-PROJECT_LOC%7D/.settings</locationURI>
    </link>
  </linkedResources>
</projectDescription>

This works fine in Eclipse but is not supported by Tycho. Tycho reports that no .settings\org.eclipse.jdt.core.prefs could be found in the individual project folders.

[laeubi]

@sthdev have you considered using a symbolic link instead?

Beside that, you might be interested in my proposal here:

• Support hierarchical project preferences eclipse-platform/eclipse.platform#89

[sthdev]

Thanks for the hint. I'll try it out.

[sthdev]

Unfortunately, this does not work.

It is possible to create a directory junction (on Windows) named .settings in a project folder, which points to the .settings folder in the repository root. As expected, Eclipse treats it like a normal directory. However, EGit does that, too, i.e. it reports uncommitted files in each .settings folder of each project (i.e. the junctions). Moreover, EGit cannot commit the junction itself to the Git repository. Probably because Git does not support plain directories, only files. Therefore, when checking out the repository, the junction is lost.

[laeubi]

Git supports symbolic links:

https://stackoverflow.com/questions/58814356/how-to-create-symlink-for-files-in-git-repository

I just don't know how well this is supported with (j)git under windows.

[sthdev]

But only for files, not for folders.

[laeubi]

@sthdev can you provide an integration-test to demonstrate the issue?

[Bananeweizen]

A colleague of mine has each separate .prefs file as linked resource, and that seems to work fine both in PDE and Tycho.

[mickaelistria]

"native" symbolic links should work fine; but .project (Eclipse) linked resources are not checked by Tycho so far.

[sthdev]

@laeubi which component is responsible for resolving the project settings? I am setting up an integration test and wondering how to name it or whether there already is an integration test for that component.

[laeubi]

@sthdev you can simply add a project in to the tycho-itest module and name it for example "linked-files":
https://github.com/eclipse-tycho/tycho/tree/master/tycho-its/projects

[sthdev]

A colleague of mine has each separate .prefs file as linked resource, and that seems to work fine both in PDE and Tycho.

That would be too cumbersome. In our case, the *.pref files in the root .settings folder of each repository are defined in an Oomph setup model. When some settings change, the setup model is updated. As soon as someone, checks out a repository with that setup model, those new settings are rolled out to that repository, as well.

In case a new *.pref file is added, your suggestion would require to add it as a linked resource in all projects and all repositories. Doing that manually is too cumbersome and error-prone. I do not know if there is an automated way to do it but it would have to be triggered by the setup model.

[sthdev]

Added PR #1626

[Bananeweizen]

I do not know if there is an automated way to do it but it would have to be triggered by the setup model.

You can trigger any (checked in) launch config from Oomph. Instead of using Oomph for distributing project preferences, I have created a JUnit test to both copy the files from a template project and to also check some additional constraints for my setups at work. Has the added benefit of breaking the CI build if such constraints fail or if the template copy operation modifies the git working dir.