Bugzilla – Full Text Bug Listing
| Summary: | [Legacy] Legacy fails when loading a contained object before its container | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Martin Fluegge <martin.fluegge> | ||||
| Component: | cdo.legacy | Assignee: | Martin Fluegge <martin.fluegge> | ||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 3.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Martin Fluegge
Created attachment 175187 [details]
Patch V1
I created a patch for the maintenance branch. But to keep compatibility the method instanceToRevisionContainment() is not renamed here. Eike, do you think this is o.k.?
CDOLegacyWrapper is an internal class. You can change it in any way. API Tooling should give you errors otherwise. Yes, that's why I was wondering. API Tooling complained that the method was removed (due to the renaming). Maybe the package is not declared internal anymore? I'll check this this evening. O.k. Found it. org.eclipse.emf.cdo.internal is not internal. Neither on HEAD nor on the 3.0 maintenance branch. It is visible to downstream plug-ins. I assume that this is a mistake. But I better ask. Maybe there is some reason for this ;) I suggest fixing this and applying the patch from bug 320837 if nothing speaks against it. (In reply to comment #4) > O.k. Found it. > > org.eclipse.emf.cdo.internal is not internal. Neither on HEAD nor on the 3.0 > maintenance branch. It is visible to downstream plug-ins. I assume that this is > a mistake. But I better ask. Maybe there is some reason for this ;) > > I suggest fixing this and applying the patch from bug 320837 if nothing speaks > against it. I remember again why this package is not x-internal: It contains CDOObjectImpl, which has to be extended by generated model plugins ;-( We can not make it x-internal. The "nicest" solution would be to move CDOObjectImpl to a public org.eclipse.emf.cdo.impl package (in analogy to org.eclipse.emf.ecore.impl.EObjectImpl) but that would break *everybody*. We can only consider to move everything else out of the package org.eclipse.emf.cdo.internal, into packages that are really x-internal... I'm reluctant to do big moves in general until we've migrated to git because with CVS we'd loose all history. Wouldn't do the move either yet. What about the following idea: We keep the patch as it is, which means that on HEAD the method is called *revisionToInstanceContainer()* and on 3.0.1 *revisionToInstanceContainment()*. Not nice, but I can keep that in mind. After switching to git we clean up the 'internal' problem and I synchronize the method names. If you agree, shall I file a reminder bug for the package move? Another option would be that we postpone this bugzilla until after the git move. But this problem is likely to occur if a containment is read out before it's container... (In reply to comment #7) > Wouldn't do the move either yet. What about the following idea: > > We keep the patch as it is, which means that on HEAD the method is called > *revisionToInstanceContainer()* and on 3.0.1 *revisionToInstanceContainment()*. > Not nice, but I can keep that in mind. Yes. > After switching to git we clean up the 'internal' problem and I synchronize the > method names. If you agree, shall I file a reminder bug for the package move? No, we don't clean up in maintenance ;-) Alright. Committed to R3_0_maintenance. Moving all open problem reports to 4.0 Undoing accidental version change. Closing. |