Community
Participate
Working Groups
We should support project-specific user settings. See bug 69640 comment 15 for a use case. See bug 68270 comment 7 for another. The simplest way to implement this would be to allow clients to obtain content type managers for a given chain of preference scopes. For the case of project specific preferences, we would pass in {new ProjectScope(), new InstanceScope()}, if project specific content type preferences were enabled.
Very cool ! ... and for 31M6 !!! Will this require any changes in the API for example in the IContentTypeManager ?
Sorry for taking so long to answer. This is not set in stone, but the basic idea is to have project specific IContentTypeMatchers. Something like: IContentTypeMatcher IProject.getContentTypeMatcher() IContentTypeMatcher contains most of the API that used to be in IContentTypeManager. This was not a breaking change because IContentTypeManager extends IContentTypeMatcher. So yes, clients would have to be changed to call the project specific content type matcher instead of the global one. Clients that do not do that would still work, but would not honor project-level settings.
(Non-functional) API is in place for M6. Implementation will happen during M7.
*** Bug 86178 has been marked as a duplicate of this bug. ***
Bill/Alain, If Core released this support (with no counterpart from Platform/UI) in 3.1, would you guys be willing/able to take advantage of the provided API and move the existing CDT project properties GUI to it? I have a basic implementation ready to be released. But since now all feature work has to have PMC approval, there would have to be a decent demand for releasing these late changes.
(In reply to comment #5) > Bill/Alain, > If Core released this support (with no counterpart from Platform/UI) in 3.1, > would you guys be willing/able to take advantage of the provided API and move > the existing CDT project properties GUI to it? Yes. What is the API to get this ? Changes in the IContentTypeManager ? > I have a basic implementation > ready to be released. But since now all feature work has to have PMC approval, > there would have to be a decent demand for releasing these late changes. Doing this will allow us to remove our own awkward content-type scheme. So there is a real strong demand for this. What do we need to do to make this happen ? Is a free beer on the next eclipseCon enough 8-)
I actually got a "go" to finish this work (since the API has already been released), so this is going to happen before M7. The API changes are in the org.eclipse.core.runtime.content package (from Runtime) and a method added to IProject: getContentTypePatcher(). CDT is the only interested party at the moment. What I expect from you guys is early validation of the proposed API (implementation to be released before Monday). We are officially in API-freeze mode, but if a significant issue is encountered in an API that has just been released, the PMC might approve minor changes. Once we ship 3.1, then it is set in stone and we will have to live with it forever. Would you have time for that?
getContentTypeMatcher() is the correct method name...
(In reply to comment #7) > Would you have time for that? Ouch! that is short notice 8-) Ok. I'll go through the drill(at least browse the new API), if you got no news .. that is good news. Do I need the latest integration build ? nightly ? ?? Thanks
Sorry, you got me wrong. What I meant is that starting on Monday, the API will be in a good shape to be reviewed/tested. My question "Would you have time for that?" was intended to mean: will you have time during this final stage in the 3.1 cycle to validate the API and implementation (for instance, for adopting it in CDT, even if in a branch)? The earlier things get settled, the better. Here is our schedule leading to 3.1: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-releng-home/3.1-endgame-buildschedule.html
> will you have > time during this final stage in the 3.1 cycle to validate the API and > implementation (for instance, for adopting it in CDT, even if in a branch)? Ok. The folks here really want that feature.
Fixed. Released to HEAD. Alain/Bill, let me know if you find any issues/have any concerns with the current API (new PRs would be good). org.eclipse.core.tests.resources.ContentDescriptionManagerTests#testProjectSpecificFileAssociations() should give you an idea on how to enable project specific settings and how to change settings for a given content type. Note that there is no API for the preference keys, but that should not prevent you from obtaining/setting the relevant preferences (the only one that must be explicitly accessed "org.eclipse.core.runtime/content-types/enabled").
