Bugzilla – Full Text Bug Listing
| Summary: | Modify GMF Notation metamodel to not depend on Ecore | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Mariot Chauvin <mariot.chauvin> | ||||||||
| Component: | Notation | Assignee: | Mariot Chauvin <mariot.chauvin> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | ahunter.eclipse, apupier, martin.fluegge, mistria, stephane.fournier, stepper | ||||||||
| Version: | 2.1 | Flags: | mariot.chauvin:
indigo+
|
||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 336706 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Mariot Chauvin
Is this a refactoring that would affect any API? (In reply to comment #1) > Is this a refactoring that would affect any API? Our goal is to not break any API. However I currently see one API break linked to the dependency removal. The fact that instances of org.eclipse.gmf.runtime.notation.View will no more instances of org.eclipse.emf.ecore.EModelElement but instances of org.eclipse.gmf.runtime.EModelElement. We only start to work on it, so other issues may come. Do you think already this API break could be problematic ? In this case, we will start to think on another way to provide a notation metamodel which does not depend on ecore (a new notation plugin ?). You will be able to turn on API tools against GMF Notation 1.4.2 to see if any errors come up. Created attachment 189467 [details]
Patch version 0.1
Anthony,
Please find a first patch to review which removes the dependency from ecore without breaking any dependency.
I tested it successfully with the ecore tools modeler, being able to reload existing diagrams and create new one, without problems.
Thanks,
Mariot.
I am seeing new code under the org.eclipse.emf.ecore package. Can you confirm that is what you wanted? We cannot add packages belonging to the EMF namespace to GMF Notation. (In reply to comment #5) > I am seeing new code under the org.eclipse.emf.ecore package. Can you confirm > that is what you wanted? Yes this is what I wanted. We added an EPackage to the notation metamodel an specify "org.eclipse.emf.ecore" as package name in the genmodel. This is the trick we use to not break the compatibility with previous versions. > We cannot add packages belonging to the EMF namespace to GMF Notation. Why ? I understand that it's mostly strongly discouraged to avoid confusion but in this case, it's only there to keep source and binary compatibility. BTW I do not find such a requirement in http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php but I may miss something. (In reply to comment #6) > (In reply to comment #5) > > I am seeing new code under the org.eclipse.emf.ecore package. Can you confirm > > that is what you wanted? > > Yes this is what I wanted. > We added an EPackage to the notation metamodel an specify > "org.eclipse.emf.ecore" as package name in the genmodel. This is the trick we > use to not break the compatibility with previous versions. > > > We cannot add packages belonging to the EMF namespace to GMF Notation. > > Why ? I understand that it's mostly strongly discouraged to avoid confusion but > in this case, it's only there to keep source and binary compatibility. > > BTW I do not find such a requirement in > http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php but I may > miss something. Ok we will try to provide another approach (with fragments) to not directly modify the gmf runtime notation. Stay tuned :) Created attachment 190071 [details]
Patch version 0.2
Created attachment 190072 [details]
a fragment for org.eclipse.gmf.runtime.notation bundle
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > I am seeing new code under the org.eclipse.emf.ecore package. Can you confirm > > > that is what you wanted? > > > > Yes this is what I wanted. > > We added an EPackage to the notation metamodel an specify > > "org.eclipse.emf.ecore" as package name in the genmodel. This is the trick we > > use to not break the compatibility with previous versions. > > > > > We cannot add packages belonging to the EMF namespace to GMF Notation. > > > > Why ? I understand that it's mostly strongly discouraged to avoid confusion but > > in this case, it's only there to keep source and binary compatibility. > > > > BTW I do not find such a requirement in > > http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php but I may > > miss something. > > Ok we will try to provide another approach (with fragments) to not directly > modify the gmf runtime notation. Stay tuned :) Please find attached a minimal patch for org.eclipse.gmf.runtime.notation. The patch enables one to use fragment, it only modifies Manifest.MF file. The fragment we provide as second attachment removes the dependency from Ecore metamodel without breaking any API. Anthony what do you think of this ? - No API break, neither source nor binary - No org.eclipse.gmf.runtime.notation direct modifications or new packages. - CDO native possible, by simply install the fragment. I think it's quite fair. We are just changing org.eclipse.gmf.runtime.notation via the patch and that is it? (In reply to comment #11) > We are just changing org.eclipse.gmf.runtime.notation via the patch and that is > it? Yep. The patch simply enables one to use fragment with org.eclipse.gmf.runtime.notation as bundle-host. The fragment we provide as other attachment, use org.eclipse.gmf.runtime.notation as bundle-host and acts as a bridge to provide EModelElement and EAnnotation implementation not dependant from the EMF one. I have committed the change, a build should run overnight so you can test. Hi Mariot, This sounds very interesting! Could you already verify that the recent GMF builds have this ability? Is the fragment included there? For CDO this would be extremely helpful because our users could regenerate their notation model for native usage within CDO, if the odd Ecore dependency was finally gone ;-) (In reply to comment #14) > Hi Mariot, > > This sounds very interesting! Could you already verify that the recent GMF > builds have this ability? Is the fragment included there? > > For CDO this would be extremely helpful because our users could regenerate > their notation model for native usage within CDO, if the odd Ecore dependency > was finally gone ;-) Hi Eike, Sorry for the lag of my response. No I did not test yest that the recent GMF builds have the patch applied, and that the mechanism of fragment we use, work as we expect but I will did it quite soon. The fragment is not yet hosted on GMF CVS, I created an eclipselabs project to work in a collaborative way on this subject : http://code.google.com/a/eclipselabs.org/p/cdo-gmf-notation/ The ecore dependency removal was the first step, we are now working on GMF Notation implementation based on CDO, and we have some code :). See bug 336709 comment 1 Thanks for the hint, Mariot! Et Joyeux Pâques ;-) Eclipse GMF Notation is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/gmf-notation. If this issue is relevant to you and still present in the latest release: * Create a new issue at https://github.com/eclipse/gmf-notation/issues/. * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) * In the GitHub description, start with a link to this bugzilla ticket * Optionally add new content to the description if it can helps towards resolution * Update bugzilla ticket * Add to "See also" property (up right column) the link to the newly created GitHub issue * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" * Set status as CLOSED MOVED All issues that remain open will be automatically closed in the next few weeks. Then the Bugzilla component for GMF Notation will be archived and made read-only. Closing as part of the move to GitHub. Feel free to re-open an equivalent issue at https://github.com/eclipse/gmf-notation/issues if you feel this is still relevant. |