Community
Participate
Working Groups
I would like to add *.prv files as C++ Source files to a global plugin_customization.ini file. I noticed that the setting lives in org.eclipse.core.runtime.prefs so I added the following line to plugin_customization.ini: org.eclipse.core.runtime/content-types/org.eclipse.cdt.core.cxxSource/file-extensions=prv However that seemed to have no effect. Is there any way we can make this work?
I presume this does not work because the preferences are initialized (DefaultPreferences.applyProductDefaults) after the content-types are processed and cached by the ContentTypeManager. Anyway, to add a file extension to a content-type, you should add a <file-association/> element to the extension point "org.eclipse.core.runtime.contentTypes".
>>"Anyway, to add a file extension to a content-type, you should add a >><file-association/> element to the extension point >>"org.eclipse.core.runtime.contentTypes"." Can you clarify what that means? Is it possible to do that accross a group of developers (like you can with a plugin_customization.ini file)?
Open the Plug-in Manifest editor for one of your plug-ins (e.g. the plug-in which contains your plugin_customization.ini file), select the "Extensions" tab, click on "Add..." and select the extension point "org.eclipse.core.runtime.contentTypes", open the context menu on this new node, select New > file-association and enter the content-type id and the extension you like. The resulting entry in the plugin.xml should look like the following: <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cxxSource" file-extensions="moc"/> </extension> You could also simply copy and paste this into the plugin.xml file (if there is one).
Beware of the typo: file-extensions="moc" should be file-extensions="prv"
It seems I haven't realized that there are multiple uses of plugin_customization.ini files. I am using it with the -pluginCustomization command line argument of eclipse as documented in: http://help.eclipse.org/help30/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html This is how I am able to set ecliipse settings accross a group of developers (by making them all run eclipse with the same plugin_customization.ini file). Just to be clear I am not writing my own plugin. I need to configure all the developers in my department to treat *.prv files as C++ source files. Hope this clarifies things.
Well, in this case, I suggest to create a plugin (or fragment) containing the content-type customization and add it to your installation.
Are you recommending that as a workaround or as a solution to this bug?
If you just want to get the bug fixed we should reroute it to the platform. We (CDT) can do nothing about it. BTW, another solution (or workaround) for your scenario is to export the preference settings and have your developers import the settings (once per workspace).
I have no problems rerouting to platform. I would prefer not to have to learn how to write a custom plugin. I would also prefer not to have any manual steps every time we have a new development wide eclipse setting.
(In reply to comment #9) > I would prefer not to have to learn how to write a custom plugin. That's actually a piece of cake, no code needed. Everyone does it. Anyway, rerouting to platform.
This happens because of the way the content types are processed. First the registry elements are applied and then the stored preferences. The key is that the default preferences don't look like they are applied. Relevant code is in: ContentTypeBuild#applyPreferences. The preferences which are stored in the instance scope are applied but the default preferences are never queried.
Moving content type bugs to the resources component.
I'm truly sorry for all the spam. Apparently I don't know how to use the "change several bugs at once" feature.
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 and remove the stalebug whiteboard tag. 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.
