Community
Participate
Working Groups
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=103083 they've defined a content type for "xmi" which is probably something EMF should do itself. Similarly for all the file types we know about, e.g., "xsd", "xmi", "ecore", and so on. We need to find out what happens if there are conflicting registrations since one could imagine more than one project defining a content type for the same extension. We should also consider generating content type registrations in the generated plugins that register a resource factory.
*** Bug 103543 has been marked as a duplicate of this bug. ***
I am attaching here a patch with changes that would implement this feature request. These changes were not committed is because it seems that the Editor support for content types is not sufficient for everything we want/need to do: 1. In order to properly handle the XML and XMI content types using the EMF reflective editors, we would need to be able to define our editors to never be used as default. This way the text editor would be the default editor for XML/XMI file and ours would be just an option under the "Open With" menu 2. Bugzilla 134331 https://bugs.eclipse.org/bugs/show_bug.cgi?id=134331 3. The XML and Text content type describers provided by the platform are in internal package making it really hard to provide an XMI describer (we would need to code it from scratch).
Created attachment 37563 [details] Patch implementing the content type support
*** Bug 131813 has been marked as a duplicate of this bug. ***
Note that support for this will come via https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 which contains working patches for the generalized URI converter support we plan to add for 2.4.
What is the status of this plan item? It's targeted for M4, but M4 has come and gone...
The book is taking at least until the end of Feb and I need Marcelo's and Dave's help to get some of these things done or even with helping maintain the schedule, so even M5 is unlikely, but you never know... Is this holding you up somehow? All the enabling work for it is completed so you can define all the content types you know about. :-P
No, it's not holding me up, but I was thinking that the content types defined by EMF may need to be used in various ways by UML2.
Just adding my two pennies here since we've had trouble in EMF Compare with conflicting content-type definitions (on .ecore mainly, see discussion here http://dev.eclipse.org/newslists/news.eclipse.technology.emft/msg04438.html). The main issue was EMF 2.4 defining a content-type "Ecore File" on files with extension .ecore, while EMF Compare defined its own content-type "Model File" on .ecore, .uml and .emfdiff files. Content-type "Model File" was used to register the files on which our comparison should be called, yet with this new "Ecore File" we are no longer called on .ecore comparisons. For now, we have found a workaround by refactoring our content-type to make it use EMF's "Ecore File" as "base-type", which effectively makes us inherit the definition of your content-type and allows EMF Compare to be called anew for .ecore files comparisons. What we would like to see is somewhat of a "base" content-type that EMF would define for all model files, allowing downstream plug-ins to register content-type bindings on this "base" instead of creating binding for each and every content-type they know of. This base content-type would be defined "blank" : only an ID and a name, and all plug-ins defining content-types for models should use this a base type. This would give something like : <extension point="org.eclipse.core.runtime.contentTypes"> <content-type base-type="org.eclipse.core.runtime.xml" id="org.eclipse.emf.ModelContentType" name="Model" priority="normal"> </content-type> </extension> for this "base" content-type, and something like : <extension point="org.eclipse.core.runtime.contentTypes"> <content-type base-type="org.eclipse.emf.ModelContentType" file-extensions="ecore,xmi" id="org.eclipse.emf.ecore" name="%_UI_Ecore_content_type" priority="normal"> <describer class="org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Describer"> <parameter name="namespace" value="http://www.eclipse.org/emf/2002/Ecore"> </parameter> <parameter name="kind" value="xmi"> </parameter> </describer> </content-type> </extension> for EMF's "Ecore file" content-type to stay with this example. Such a base would be useful for EMF Compare to allow comparison as models for everything under this "Model" content-type, it could also be used for bindings with editors ...
Coming back here after a little more research on this particular issue. It appears this new content type that was added in EMF 2.4 breaks any backward compatibility attempt we can make to allow our compare editor to work on both Eclipse 3.3 and Eclipse 3.4. Our best shot still logs an error in the error log when loading our plug-in ( see https://bugs.eclipse.org/bugs/show_bug.cgi?id=217986 ). The same issue will arise for any third party plug-in defining an editor on ecore files via content-type binding (extension point "org.eclipse.ui.editors", right-click > New > Editor then on this editor right-click > New > contentTypeBinding). As we aim to maintain backward compatibility as much as possible with Eclipse 3.3, this kind of issue is quite a blocker. Obviously, this also means that if a content-type has been registered on other "model" files such as uml or xsd, creating an editor (or maintaining compatibility) will force us into creating one contentTypeBinding for each distinct content-type declared we know of ... logging an error in the user's error log for each that is declared by a plug-in he has not installed. I'm attaching here three patches that would implement something like I described on my comment above on EMF 2.2, EMF 2.3 and EMF 2.4 (so as to allow true backward compatibility for EMF based third-party plug-ins defining content-types on ecore). Also attached is a screenshot of the result on the content-type preference page. AFAIK, this cannot break anything in the existing plug-ins (both EMF and EMF based third-party) and can be implemented on all versions of EMF since content-types appeared in Eclipse. Can this be a possible/acceptable addition to EMF? This would null out every compatibility problems we've add at least with EMF Compare.
Created attachment 89003 [details] patch aimed at R2_2_maintenance branch
Created attachment 89004 [details] patch aimed at R2_3_maintenance branch
Created attachment 89005 [details] patch aimed at the CVS HEAD for EMF 2.4
Created attachment 89006 [details] screenshot of the resulting preference page
I'll need to review these changes when I have time (I just got back from vacation), but I don't believe we can go back and add content types to maintenance stream.
Laurent, Defining kind of an abstract base content type for EMF seems problematic to me. Consider if/when we complete the work for https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267 that we'll can have resource type that contains a binary serialization that isn't XML. Consider also resources like Emfatic, or ones based on an xText textual (non-XML) serialization. Such things cannot derive from the same abstract base type. And our Java model even has support for building a model for *.java resources but there's no way JDT will use EMF's content types. I wonder, since EMF can read any XML file, could you use org.eclipse.core.runtime.xml as your base to achieve close to the same goal?
Created attachment 95422 [details] Poorly tests patch for an XMI content type.
Created attachment 95475 [details] Update of the previous patch I've added an EMOF content type in org.eclipse.emf.ecore.xmi and switched all of the file extension based editor registrations in org.eclipse.emf.ecore.editor to use content types instead. I also changed the name of the XMI content type to "XML Metadata Interchange (XMI)". I noticed that the heavily extended base content types (Text and XML) don't include the word "File". Also, I thought some users might not recognize XMI (after all, this will show up in the preferences whenever EMF is installed). Oh, and I just noticed that there are ecore and emof team file types declared in org.eclipse.emf.ecore.xmi that are already declared in org.eclipse.emf.ecore. Those should probably be removed.
I'm now using the new XMI content type as the base (when appropriate) in bug 204987. So, it depends on this one.
It seems to me that content types that are recognized by namespace should be version-specific (particularly in cases where the namespace includes version information). For example, the "EMOF File" content type should be labeled "EMOF 2.0 File" and defined something like this (similar to the definition for CMOF in UML2): <extension point="org.eclipse.core.runtime.contentTypes"> <content-type base-type="org.eclipse.emf.ecore.xmi" file-extensions="emof,xmi" id="org.omg.mof.emof_2_0" name="%_UI_EMOF_2_0_content_type" priority="normal"> <describer class="org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Describer"> <parameter name="namespace" value="http://schema.omg.orb/spec/MOF/2.0/emof.xml"> </parameter> <parameter name="kind" value="xmi"> </parameter> </describer> </content-type> </extension> Note here that the namespace value has been changed to the correct namespace URI as defined in the MOF 2.0 specification (this is a bug with the current namespace used by EMF).
#20 perpetuates a typo with "http://schema.omg.orb/spec/MOF/2.0/emof.xml" UML 2 Issue 7783 in http://www.omg.org/docs/ptc/06-04-01.pdf gives "http://schema.omg.org/spec/MOF/2.0/emof.xml"
(In reply to comment #21) > #20 perpetuates a typo with "http://schema.omg.orb/spec/MOF/2.0/emof.xml" > > UML 2 Issue 7783 in http://www.omg.org/docs/ptc/06-04-01.pdf gives > > "http://schema.omg.org/spec/MOF/2.0/emof.xml" > Oops, of course I meant "http://schema.omg.org/spec/MOF/2.0/emof.xml". That's what I get for copying and pasting from the spec. My intent here was to point out the upper casing of "MOF" and the use of "xml" instead of "xmi" as the extension used in the URI.
I want to check in my changes for bug 204987, and that requires the new XMI content type. So, I'll check in just that part. I'll leave the EMOF part out pending further discussion.
Those changes are committed.
Created attachment 96130 [details] Changes for EMOF support These changes are to support EMOF content type and also fixes the namespace used to serialize EMOF to be the new correct one. The old one can still be consumed for backwards compatibility purposes. Note that these changes also support a namespace pattern for specifying the namespace, since this allows one to use "|" for choice and any other pattern that might be useful.
Created attachment 96145 [details] Fixes Kenn noticed I cross wired the Ecore/EMOF labels.
I've removed the extensions registration from the Ecore editor declaration (since there's a content type one now) and committed the changes for EMOF. More to come...
Created attachment 96702 [details] Should EcorePackage have eCONTENT_TYPE It would seem more consistent if EcorePackage had an eCONTENT_TYPE which means it ought to be specified in Ecore.genmodel. What do you think? Maybe EMOFExtendedMetaData ought to have a CONTENT_TYPE constant as well?
Sure, both of those make sense. I'll do that.
Created attachment 97619 [details] Patch for remaining content types
Created attachment 97646 [details] Patch for library example
Created attachment 97736 [details] Remaining change to SDOUtil Almost everything's committed. I have one pending change to SDOUtil, where I noticed that the resource set for a datagraph gets initialized with overriding registrations for .datagraph, .ecore, .emof, and .xmi if the global registry doesn't have the expected registrations, and I corresponding ones for content types. I'm not really sure if this is necessary or desirable, I only noticed it while looking over the existing uses of Resource.Factory.Registry.getFactory(URI) and ResourceSet.createResource(URI). Ed, thoughts?
Created attachment 97737 [details] Latest changes to library example I also haven't committed the changes to the library example yet. This patch adds one additional change in the model wizard, which we're also generating now: performFinish() uses the content type when creating the resource. If no one has any objections to these changes, I'll commit them for our build on Tuesday.
I'm abandoning the proposed change to SDOUtil. Content types aren't relevant in the SDO case since we don't actually end up with distinct files. Having heard no objection to the library example changes, I'm committing that for our M7 build tomorrow.
All of the changes for this bug are committed to CVS for EMF 2.4.
*** Bug 230261 has been marked as a duplicate of this bug. ***
Fix available in HEAD: 2.4.0M7 (S200805052017).
Fix available in HEAD: 2.4.0.I200804291800.
