Community
Participate
Working Groups
It turns out that the Eclipse team added the "filenames" attribute to the editor extension point. This is to allow binding an editor to a specific filename -- e.g. "xxx.xml, yyy.xml". For the same reasons that this was added to the editors extension it is now also needed in compare to associate compare editors with those specific filenames.
We'll need both compare/merge extension points handled -- the structured diff viewer binding and the content viewer binding.
I don't like this approach since it doesn't scale well: everyone has to add new filename attributes to their extension codes. I would rather like to see a single mechanism where I can associate a file name with a content type (independent from any other extension point). And if we consider this content type equivalent to the existing file extension based type, we wouldn't need new "filename" attributes everywhere.
Yes, the work scheduled for 37668 should create that generic facility. But if it does not make it for E3, the feature is still needed to support EJB deployment descriptors. I'm not happy with the solution, but the precedent has already been set.
I'll add the requested workaround to the compare plugin if we decide not to do #37668
Is this change needed in addition to 37668? That is, does 37668 handle only file inspection, or will it also genericize the filename pattern facility for binding to a type?
Rafael, with the new ContentType mechanism is it already possible to contribute a contentType (e.g. for JSP) and associate a file name pattern with it (*.jsp), so that I don't have to add support for this in my own plugins?
That is correct. Content-types can be contributed and associated with file specs (names and/or extensions). Editors could then be associated to content-type ids instead of to file specs. The content type registry is suitable for both name-based and content-based content type lookups. However, the thing is still an ongoing work, but I hope to have most of it straight for next Tuesday's integration build.
Very good! So I will add a new attribute for content-type ids to my Compare Viewer registry. And my lookup strategy will first use the old file extension mechanism and then the new content type mechanism.
I assume that the extra checks for file extension are required only for plugins that were public and already have extenders doing it that way. But for new plugins I presume that the way to go here is to use only this new facility. That is, to define bindings by a combination of content and filename patterns. Is this correct?
A few plugins are expected to be contributing content types (usually core, headless plugins). Ideally, plugins providing editors and UI in general would be associated to well-known content type ids (instead of file specs), giving an extra-level of indirection. Please note that right now the content type registry is currently *not* used by the UI at all (hopefully it will be).
Re #9: Yes, your assumption is correct. I'm checking for the "old" file extension attributes only for compatibilty reasons, but new clients (or clients who are willing to change their code) should use the new content type attributes.
Re #10: The low-level EJB artifacts that depend on this stuff coming in (e.g. deployment descriptors) are currently using the editors hack for searching filename patterns in addition to extensions. So they can live without the UI being hooked up for this release, so long as the Eclipse and Aurora compare interfaces are hooked up. (I hope that the compare UI was not what you meant.) But the Rational model artifacts could use the inspection typing mechanism now because they share a common token in the files which will be used by ClearCase for typing. This will be derailed a bit if the typing mechanism does not propagate to all the known interfaces. Aurora compare will implement this feature as soon as possible and hope for the best. I'd hate to stay with file extensions for our client plugins (e.g. modeler and visualizer bindings) when the better mechanism is so close.
For I20040420: - added new contentTypeBinding elements to all 5 Compare extension points. - the old "extensions" attribute still works, but the new contentType is checked first. Example: the following contribution associates a special structureCreator with the javaProperty content: <extension point="org.eclipse.compare.structureCreators"> <contentTypeBinding contentTypeId="org.eclipse.core.runtime.javaProperties" structureCreatorId="org.eclipse.jdt.internal.ui.compare.PropertiesStructureCreator"> </contentTypeBinding> </extension>
