Community
Participate
Working Groups
There should be a way to save resource properties inside projects (like preferences are saved in .settings folder) instead of in the metadata folder. This allows users to share properties settings in a team environment. Something similar is already being done with the File Charset/Encoding property. The property values are actually stored in the project scope of preferences. And the CharsetManager maintains sync-ing up the resource with its preference (having a resourcechangelistener) Maybe just make CharsetManager more general and just have a get/setProperty(IResource, key) That way there's only 1 ResourceChangeListener managing all the preferences.
What are you looking for that isn't already available? Many plugins already store properties in the .settings folder, such as JDT core with compiler settings. Use IPreferencesService API with an instance of ProjectScope: IScopeContext[] scopeContext= new IScopeContext[] { new ProjectScope(project)}; String lineDelimiter= Platform.getPreferencesService().getString("your.plugin", "your.pref.key", null, scopeContext); Others can listen for changes to these settings using an IPreferenceChangeListener. The character set is a fairly special property on a resource, because any client that is interested in character content in files should be treating charset change as equivalent to a content change on the file. I.e., this particular property is of interest to almost all resource change listeners. This isn't the case for arbitrary third party properties associated with a resource.
The .settings folder is currently used for project preferences, not resource preferences. The problem I would like to solve is how to associate a preference per resource/file. The approach I am trying to take now is something similar to CharsetManager where I use the ProjectScope to store the preference, but the key is generated based on [fullPathOfResource]//[preferenceKey] The problem is that if the file is renamed or moved, I need to make sure the preference is moved accordingly, which is why I would need a ResourceChangeListener in my preference manager. I figure if others may want to do something similar, it's better to have 1 central place to manage resource preferences.
I think this is a good idea; I have had to implement a mechanism to store the properties for all of the resources in a project into a .projectProps file which can then be checked in and out of source control. The reason my application uses persistent properties is to identify the type of the resource so that the right icon and other things may be selected by the navigator content provider. I also use the Eclipse editor property to set the preferred editor. I would be happy to work on a patch for this if that would help.
(In reply to comment #2) So as I understand you are working on some kind of ResourcePropertyManager which would allow me define my own property for resources in projects, and this property would be stored in .settings/myplugin.prefs in a charset-like way and this manager would handle renaming, moving etc. of resources. Right? Anyway it seems that you are not working on it any more. (In reply to comment #3) > I think this is a good idea; I have had to implement a mechanism to store the > properties for all of the resources in a project into a .projectProps file > which can then be checked in and out of source control. Why don't you want to use .settings/*.prefs instead of this .projectProps?
(In reply to comment #4) > (In reply to comment #3) > > I think this is a good idea; I have had to implement a mechanism to store the > > properties for all of the resources in a project into a .projectProps file > > which can then be checked in and out of source control. > > Why don't you want to use .settings/*.prefs instead of this .projectProps? > I just did not think of it. I would be happy to generalize my stuff and put it in a .settings/*.prefs file. I was not aware there were standards in this area, or how others used these types of files. Can you give me any hints in how these files are used in a standard way? The way my stuff works now if that if I detect any resource file being added (using the resource change listener), then I update the .projectProps file with the properties for that resource. In my implementation the properties on a give resource don't change after the resource is initially added. Obviously this would need to be generalized. Also, when I detect a .projectProps file being added (also using the resource change listener), I read it and use it to set the persistent properties on all of the resources it refers to.
I would start with the CharsetManager. I think that our ResourcePropertyManager could work in a similar way. API should be similar too, see the comments #0 and #2. The difference is that you have to pass id of the plug-in that sets this property and the key of the property. The manager should be aware of those properties and respond to move, rename operations on resources.
(In reply to comment #4) > (In reply to comment #2) > > So as I understand you are working on some kind of ResourcePropertyManager > which would allow me define my own property for resources in projects, and this > property would be stored in .settings/myplugin.prefs in a charset-like way and > this manager would handle renaming, moving etc. of resources. Right? > > Anyway it seems that you are not working on it any more. Yes, I ended up implementing some kind of ResourcePropertyManager that was pretty much a generic form of CharsetManager. And the API was: /** * Returns the value for the given key in the given context. * * @param key * The property key * @param resource * The current context or null if no context is * available and the workspace setting should be taken. Note * that passing null should be avoided. * @param recurse * whether the parent should be queried till property is found * @return Returns the current value for the key. * @since 1.1 */ public static String getProperty(String key, IResource resource, boolean recurse) /** * Sets the value for the given key in the given context. * * @param key * The property key * @param resource * The current context. Note context cannot be * null. * @param value * The value to set for the key. If value is null * the key is removed from properties. * @since 1.1 */ public static void setProperty(String key, IResource resource, String value) throws CoreException
It looks like this went pretty far along, is this still being considered?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
