-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support hierarchical project preferences #89
Comments
IIRC @merks started to prototype something related in the context of Oomph a (long) while ago? |
Yes, long ago I started implementing something that would automatically copy/propagate project-specific preferences between projects where one could specify which project is the "prototype" from which the preferences should be copied. But I never completed this work such that it's actually in use by any project... |
Are there some comment on how this works? It has been a while since I wrote this down, but now I think my initial proposal could even be adjusted by instead of
to simply delegate e.g. overwrite anything from the lower levels so we have:
and the highest value wins. My goal here would clearly be that one do not need to copy anything ... so once we might be able to have what @mickaelistria likes from intelij/vscode that there is only one single folder in the workspace storing all ide specific configurations. |
Are we talking here about |
I think the "parent" of a project is always the workspace so this seems not useful, not sure how
Why not? But I'm wondering if there are really people using a rmfs for their project to work on entirely? |
So, for each IProject it will go up from its "Location URI" through the local file system, looking for |
yes, this is for example how maven works with the |
I believe that Eclipse (at least with m2e) already has a notion of hierarchical project structures (see the project explorer), which might be used to know how far to go "up", because when working with Git, the projects might not reside inside the workspace folder (for example /git/my.project/base/plugins/my.plugin vs. ~/workspaces/MyProjectWorkspace/), because workspace settings are not committed to git. |
While working on eclipse-equinox/equinox#446, I also thought about this and how to implement this. In general I think this a good approach, but it should only be implemented in the Project-preference scope so that the project-scope in itself is hierarchical, while being the most specific scope of the project, instance/workspace, configuration/installation and hopefully soon user scope (plus the default scopes) hierarchy. If a value is search in the project scope, the closest preference file should be searched first and if the key is not found the further parents should be searched until a value for a key is found. From an UI point of view, the shared preferences stored in an
I would propose that nothing changes only if the requested key is not present in the existing preference file. If the requested key is missing it should be search in the parent directories
I don't think we should have Furthermore by default only the parent directory should be considered in order to prevent potential confused if eclipse-equinox/equinox#446 is implemented as suggested and a workspace is located within the user home plus to improve the performance (if performance is a problem depends on the exact implementation). Nevertheless it should be possible to configure the number of considered parent directories easily respectively to configure that the parent
I think the workspace (scope) should not be considered here. This should only be done as part of the project scope. Of course it might happen that coincidentally the workspace root is equal to a parent directory containing a |
Not really, the project explorer is just showing the project hierarchically, it's a UI trick to hide some content from a project a show a project in place of a folder, not something that is directly taken from the underlying resource model. But there are utility to resolve the "deepest parent project" or things of that sort. Those could be used to build a kind of ProjectPreferenceStore that would delegate to parent project if requesting a particular value that's missing in project settings. |
Currently project preferences are stored in a folder named
.settings
this has the drawback that if one want to configure an aspect for a set of projects (e.g. formatter settings, compiler preferences, ...) one need to duplicate this (and keep them up to date) for each project. Also wen VCS comes into account the same files need to be versioned multiple times.To mitigate this and given that most projects have some hierarchical nature (e.g the usual
<projectroot>/plugins/<myproject>
) I'd like to propose the following enhancement (usingorg.eclipse.jdt.core.prefs
as an example):.settings/org.eclipse.jdt.core.prefs
nothing changes.settings/org.eclipse.jdt.core.prefs
then first a file.eclipse/org.eclipse.jdt.core.prefs
is searched and if found that is used, if that file is not found, the parent folder is checked for this until the root is reached<workspace-root>/.eclipse/<project-name>/org.eclipse.jdt.core.prefs
is searched as a last resortThis would allow to have a variety of different use cases:
<projectroot>/plugins/.eclipse
folder.<projectroot>/.eclipse/org.eclipse.core.resources.prefs
to force UTF-8 for the usual source folders.The text was updated successfully, but these errors were encountered: