Community
Participate
Working Groups
Artifacts are currently typed in several ways, with special extensions used by some components to allow for previously unsupported content type definitions (e.g. file name pattenrs instead of extensions.) Since we would like to be able to use the new content type by inspection method to define our resources in all circumstances, we feel that all components should be brought on board to allow binding of extensions by content type. In concert with other fixes (78652, 78653), we would then have a universal method that can type any file or stream reliably.
I have no idea what you are asking for. Please be more specific.
Compare was actually the first component to adopt the content type API. A more broad adoption of this API is planned for 3.1. Related bugs: Bug 37668 - Content-type-based editor lookup Bug 69647 - Need showURL API Bug 71225 - Define viewer for a given content type
Very nice. Thank you. Looking forward to a univeral artifact typing mechanism in Eclipse.
Can this be closed as a duplicate of one of those then?
That's your call, but I think that this request is a superset of all the others and maybe more. That is, I am asking to have the content-type mechanism become the standard mechanism by which artifacts are typed within Eclipse. If we close this one against one of the others, then we risk a partial solution in the next release. It will basically depend on who has time to look at each of those and on whether that list of requests is complete (i.e. covers all areas that need content-type bindings inside Eclipse.)
ClearQuest has a parent-child concept that allows a number of bug reports to be related. Does the dependency tree allow the same thing? In which case we could hook this one up to the others you quoted. They could be co-dependent, assuming that circular dependencies don't freak the system out.
Bug 37668 (a 3.1 plan-item that slipped from the 3.0 plan) is very comprehensive and also requests that all content type registries in Eclipse to be consolidated (not only in the context of editors). I suggest adding any extra-requirements there and marking this one as a duplicate (that one has a long list of subscribers so it is better for gathering feedback from other interested parties). Re: using dependencies in Bugzilla - it is a common practice to depict a bigger problem report into more specific (e.g. per component) PRs and then mark the general one as depending on the more specific ones. W.r.t. circular dependencies, not sure that is supported. We usually use regular Bugzilla bug references (as the ones in comment 2) when we want mutual references.
I will take your suggestion and keep this PR as the uber PR for tracking improvements to the content type story in 3.1. Bug 37668 is currently more about editor association than anything else. Moving to runtime, where the content type infra-structure lives. Andre, I hope you don't mind if I hijack this PR (there was nothing here for compare to do).
Rafael, no problem. Feel free to hijack even more of my PRs :-)
Updated the content type doc accordingly: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/content_types.html
An update on this: Platform/UI has added support for editor/content type associations (bug 37668), which was one of the most important scenarios. Editor contributors in the SDK are being asked to migrate to the new extension markup (bug 89232), and that should happen during M7. The other scenarios I mentioned before (comment 2) are not likely to be supported in 3.1.
The "Search>File Search" feature also needs to respect the content type.
Alan, could you please open a PR against Platform/Search describing how you expect search to use content types? You could then mark it as blocking this one. Thanks.
All the work planned for the 3.1 cycle has been done. The only remaining bug (bug 71225) may be addressed for a future release, but we can say today that the Eclipse SDK is as content type aware as it gets. Closing. If there are any required features that are not currently addressed in the context of content types, please open specific problem reports against their corresponding components (Platform/Runtime would be the right choice only if the issue is related to the content type infrastructure).
