Community
Participate
Working Groups
EMF sources have been re-structured. Ecore.ecore used to live in src- ecore/model. Now it's at just model. More sensible, and since it now forms part of a binary rather than source import.
Created attachment 22857 [details] ediagram.* fixes
[Bugzilla's weird today - 3 attempts at one message!] Attached are fixed ediagram.ecore and ediagram.genmodel that refer to the new location as platform:/resource/... avoiding the need to import the EMF project. Also attached is an ediagram.ediagram that could be used to maintain ediagram.ecore - very dangerous, so more just a visibility aid. There is a strange quirk. If ediagram.ediagram is opened without importing org.eclipse.emf.ecore the Ecore is not resolved and the Outline barfs on the null names. If org.eclipse.emf.ecore is imported, it's all fine. N.B. These files are all ASCII not Binary as in CVS.
*** Bug 104846 has been marked as a duplicate of this bug. ***
I have no idea why simply using platform:/resource/... finds Ecore.ecore even if the plugin is not imported in your workspace. According to this document -- http://eclipse.org/emf/docs.php?doc=docs/whatsnew/tools2.1.html#binary -- it should be platform:/plugin/... That certainly solves the problem that Ed mentioned in comment 2 with the ediagram.ediagram file. However, it introduces another problem in that changes to ediagram.ediagram can't be saved anymore (when using the GEF EDiagram Editor). I've released some initial changes, and will release any other additions or corrections once I get a chance to talk to somebody from the EMF team.
Ecore should be referenced as http://www.eclipse.org/emf/2002/Ecore. In my enhanced EDiagram, I have added a third Browse source for Browse Packages so that registered models may be imported from the EMF Package Registry. In my enhanced outline that gives a full ResourceSet view I can then re-use an EcoresSubPage between NewWizard Dialog and ImportResourceAction so that the active resources are maintainable by Import/Delete and by DND from the workspace. I also support a read-only attribute that my be enforced from outside or imposed by the user so that edits to referenced models are inhibited. This requires that isDirty is consistently maintained as a Resource not CommandStack attribute and so requires each Command to pre-validate all objects it touches for read-write permission and set each Resource modified in redo() or perhaps unmodified in undo(). SaveAs is achievable by changing the URI property of the Resource. The support for multiple sheets allows renaming to consistently apply across multiple Resources in a single ResourceSet; I probably need to support genmodel too, so that it updates without a need to reload. Some of this, particularly the third Browse button is easily incorporated into EDiagram. Changing the outline is a bit harder. Changing Command to support validation actually moves in the EMF direction with a prepare() method. This should all be downloadable from GMT/UMLX this weekend.
Fixed. Ed, I had trouble running the UMLX example (java.lang.UnsupportedClassVersionError: org/eclipse/gmt/umlx/editor/EditorPlugin (Unsupported major.minor version 49.0)) and wasn't able to see what your changes. I have changed the references to Ecore.ecore to be of the plugin format and have also enhanced the wizard to allow specification of ecore files in the plugin format. A better way to support this would be to support read-only graphical elements. But a warning saying such ecore files can't be saved will suffice for now.
The changes do not seem consistent Ecore is referred to in 2 different ways: <eClassifiers xsi:type="ecore:EClass" name="ReferenceView" eSuperTypes="#//Link"> <eStructuralFeatures xsi:type="ecore:EReference" name="eReference" eType="ecore:EClass platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EReference"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="oppositeShown" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/> </eClassifiers> though at least the EMF sample ecore editor recognises them as the same. I recommend the http: name. Re: UMLX. I have just downloaded from the Update Site into a clean Eclipse 3.1 + EMF 2.1.0 + GEF 3.1 without trouble. Is your Eclipse running on Java 5? If I run on 1.4.2 it fails but with a CNFE. You should also be able to install org.* from CVS. I've fixed some problems with the source plug-in and am catching up on your most recent improvements, but it should be ok. Is it possible that a GEF classpath has become too prominent? there are four or five GEF classes that I have copied wholesale to fix one liners. But I have changed all their packages. I hope to refresh and 'announce' (lightly publicise) UMLX 0.0.0 this weekend after I've incorporated a couple of examples.
(In reply to comment #7) > though at least the EMF sample ecore editor recognises them as the same. > I recommend the http: name. I've made this change. > Is it possible that a GEF classpath has become too prominent? there are four or > five GEF classes that I have copied wholesale to fix one liners. But I have > changed all their packages. I am not sure what you mean by this.
I was trying to make a suggestion as to how an obscure problem might be arising. For instance since LabelDirectEditManager is repackaged without change in UMLX as org.eclipse.gmt.umlx.editor.views.LabelDirectEditManager, there might have been a possibility that a bad classpath could have left you partially using org.eclipse.gef.examples.ediagram.edit.parts.LabelDirectEditManager. Consistently using JRE 1.5 is a much simpler solution. I should probably change the UMLX binary compatibility to allow at least 1.4 execution.
I've undone the change mentioned in comment 8, and reverted back to using the platform:/plugin format. When using static packages, the ecore file is not loaded in the same resource set, and in fact, the loaded class' resource set is null. As a result, we get an NPE when bringing up one of the property celleditors. Ed Merks suggested that the plugin format is the better way to go anyway since the http format is mainly for EDataTypes.
