Community
Participate
Working Groups
I asked Ed Merks about what exactly the "Resolve Proxies" option mean (http://www.eclipse.org/newsportal/article.php?id=39654&group=eclipse.tools.emf#39654). It looks like we made a mistake by setting "Resolve Proxies" to false in the past. "Resolve Proxies" means that the reference is not expected to be proxy, while we do allow it to be proxy (i.e. links to diagrams in a different resource). Not having "Resolve Proxies" option for "diagramLink" reference results in returning proxy object for DiagramLinkStyle#getDiagramLink() all the time, unless resolved manually, so EMF by itself cannot resolve it. Hence, CrossReferenceAdapter#resolveAll() wouldn't resolve the diagramLink. If the resource containing the diagram the link is referencing is loaded, but the link hasn't been resolved manually The inverse cross references of the diagram wouldn't have the diagram link features from diagram link styles that didn't resolve diagram link proxy manually. BTW, you can always get an unresolved diagram with a basic get. I don't think that diagramLink proxies will be resolved automatically when resource is loaded also, because of basic get. They will be and most likely are resolved if a name of the diagram is displayed by the editpart corresponding to a view with diagram link on it. How about we try automatic proxy resolution for diagram link styles in 2.2?
Adding Mike and Chris so they can add their comments.
Hi, It doesn't sound too dangerous, but I wonder what would be the reason to force proxy resolution? To me, keeping it proxy has certain benefits given usecases for the linked diagrams. Unless really important, I'd refrain from changing it. Artem.
As stated in the description, the field will only be resolved if accessed via eGet() or getDiagramLink(). If the field is never access, it'll never be resolved. If current applications are storing intra-resource references using this style, they won't be affected because they're not storing the proxy. If current applications are storing inter-resource references using this style, they'll hit the same issue that we have, which is that the reference to the diagram is never resolved in the model. In particular, the ECrossReferenceAdapter (and its various subclasses), make assumptions that a call to resolveAll() will force the resolution of the referenced Diagram object, which will then allow the indexer to "see" and find the link. This leads to errant behavior in search, which can cause problems in secondary clients, like refactoring. The end result is that it's not possible for the indexer to find the link when the DiagramLinkStyle is in memory; _even_ if the _referenced_ diagram is already loaded. Even though it's loaded, the proxied field isn't updated to point to the _referenced_ diagram. We need the field to be enabled to resolve its proxy in order to fix errant behavior. In response to comment 2, we need the diagram to be resolved first for the indexer to work. Second, we do actually show the nested diagram content in the referencing diagram. For the referencer to show the diagram content, the diagram must be resolved.
Created attachment 126904 [details] proposed patch for 2.2 proposed patch for 2.2. "Resolves Proxies" == true for DiagramLinkStyle#diagramLink and MultiDiagramLinkStyle#diagramLinks, code regenerated for: DiagramLinkStyle HintedDiagramLinkStyle MultiDiagramLinkStyle
Created attachment 126907 [details] 2.1.3 compatible patch Ptach compatible with 2.1.3, i.e. 2.1.4 Whiteboard patch, if applicable.
In our code, we use EcoreUtil.getURI(diagramLinkStyle.getDiagramLink()), hence non-resolved proxies are good for us. However, resolved EObject won't harm in this case. To me, special handling of that "always proxy" DiagramLink object is unfortunate, but reasonable effort, and treating it as a regular EMF object (e.g. processing them uniformly with ECrossReferenceAdapter) may cause performance issues. Hence, neither +1 nor -1, just 0 ;)
Hi Artem, So with a "0", does that mean you do not oppose the patch? ;)
> So with a "0", does that mean you do not oppose the patch? ;) Well, yes. Can't support nor can't object. My concern is performance, and once patch's applied we'll see if it has some grounds.
Committed the fox for 2.2.
2.1.3 Patch looks good. Please commit to R2_1_Maintenance. The version of the org.eclipse.gmf.runtime.notation bundles also needs to change to 1.1.4 to indicate a change post GMF 2.1.3.
Committed the fix for maintenance stream
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
