Comment 1 Miles Parker 2011-09-15 14:49:06 EDT

I assume the java elements are extraneous.

This is actually a bit of a deeper issue that we've discussed before but we need to keep thinking about. Given:

1. We track elements at the model -- e.g. Ecore -- level, not the view -- e.g. GMF Node -- level.
2. The model elements can be added in many different ways -- e.g. Ecoretools diagram, Ecoretools outline editor, eventually Ecore diagram editor.
3. These model elements are contained in different resources.
4. (Resources typically map to files, but we can't rely on that.)
5. There is a specific containment relationship between a model element -- e.g. EClass -- and resource -- e.g. ".ecore" file.
6. However, there is not a specific containment relationship between a specific given resource and the model component *from the users point of view*. For example, a user might open an ecorediag file and add elements without ever opening the related ecore file.
7. A diagram may reference elements from multiple resources.

Theis all means that the situation is unlike say the Java context situation where ultimately there is a one to one mapping between a given element and an IFile.

Now, It would seem reasonable to simply legislate that we cannonize .ecore to do this, but given 6 it's problemattic. Perhaps there is some other Context framework mechanism that would help with this, but the only solution I can think of right now is to do this:

1. Come up with some kind of weak reference style sweep and delete mechanism, where every time we remove a resource, we a) go through the list of all contained items within that resource, b) find the matching elements in the referenced ecore resources(s) and then c) go through all of the elements in each resource -- loading all of their related resources (7) -- and check to see if there is a path to that element form that resource.

2. Create a hidden special context type or use the ecore content type to legislate a logical model that is based on the ecore resource but does not point to the actual resource. We might need to do some kind of reference counting (? :O) and would still need to go through step c) above when the last element is removed.

See also bug 352009 -- this was discussed at the beginning in another bug but I can't find it now. It occurs to me that Benny might have some ideas given his recent work with the logical models.

Comment 2 Miles Parker 2011-09-15 15:08:51 EDT

See for context bug 357768

Comment 3 Steffen Pingel 2011-09-15 15:28:33 EDT

I understand that we we can't necessarily identify a resource but if we know the resource as in this example we shouldn't the interest be propagated? Otherwise focusing in the Project Explorer won't work.

Comment 4 Miles Parker 2011-09-15 15:46:07 EDT

Actually, we should always be able to identify at least one unique resource, the issue is sort of the inverse. Sorry, I'm sure I'm making this issue seem even more complex than it is.

Something else I should explain...we don't actually track the root package -- all EMF models have one and only one root package and that's the top-level resource package. I'm not sure if that's the issue, I'll look at your workspace and try to figure that out.

Comment 5 Miles Parker 2011-09-21 16:49:40 EDT

There are a bunch of interrelated issues here. I'm going to try to consolidate them into this one bug.

Comment 6 Miles Parker 2011-09-21 16:51:58 EDT

*** Bug 357768 has been marked as a duplicate of this bug. ***

Comment 7 Steffen Pingel 2011-09-21 17:28:04 EDT

(In reply to comment #4)
> Actually, we should always be able to identify at least one unique resource, the
> issue is sort of the inverse. Sorry, I'm sure I'm making this issue seem even
> more complex than it is.

What about models that are not resource based?

Comment 8 Miles Parker 2011-09-21 17:49:52 EDT

(In reply to comment #7)

> What about models that are not resource based?

OK, we need to be really careful about terms now. If you mean EMF Resource based, then there is no such thing. That's what makes them so attractive because every model is contained by one and only one EMF Resource with a strict URI. But that doesn't mean that the URI will look anything like a typical Eclipse resource URI.* If you mean "IResource" i.e. in the "mylyn.resource" sense, then that is a good question because there we know for sure that we'll have that case show up a lot.

This is why I think it makes sense to stick with the EMF resource URI as the ultimate thing that we're propogating interest across, but it seems that we also might want / need to propagate to the (Mylyn) 'resource' type as well. Thinking about it some more, I think we actually need a different content type altogether for this, like "emf" to represent emf resources. Right now, we're using "ecore" but that's elided with an ecore model *instance*.

I think there are a bunch of related issues here and that's why I'm going to try to gether them up in this one bug.

*They could be for example a CDO model which is hosted on some kind of distributed system somewhere or some case that doesn't even support a hierarchical style URI, perhaps a GUID or something. Like mongo:/<db-name>/<class-based-collection-name>/<id-of-object-in-collection/ (see http://www.eclipse.org/forums/index.php/mv/msg/203479/650609/)

Comment 9 Steffen Pingel 2011-09-22 04:02:44 EDT

We need to propagate interest to workspace resources if we can determine a workspace resources (e.g. the URI points to a workspace file). Otherwise filtering in navigator views will not work reliably. This needs be covered through regression tests.

Comment 10 Miles Parker 2011-09-22 12:55:37 EDT

OK, so here's how all the pieces relate.

For domains: (e.g. user views ecore model in project explorer, etc...)

1. Model elements have 1..1 unique handles. Model Element Type: "ecore" (or "uml2..")
2. Model elements have *..1 unique root packages.
3. Packages are model elements. Package Element Type: "ecore".  (We were treating package and resource as equivalent, but I've just changed that to make them separate explicit interest elements.)
4. Root Package elements have 1..1 unique resources. Type: "ecore" perhaps should be "emfresource"
5. EMF Resources have 1..0 Workspace Resource ("platform:/resource..", IFile) 

For diagrams: (e.g. user opens an ecore_daig)

1. Diagram elements have 1..1 domain model elements. Model element type: "ecore"  (or "uml2..")

So given this, if a user selects an element in the diagram, it should a) mark the domain ("ecore") element as interesting, b) propagate up to parent package c) to parent "ecore" resource and then d) to workspace resource IFF that exists. It won't propagate to the diagram file itself but that's fine, because the only way for the user to edit the diagram is to actually have it open in an editor.

This all works as outlined above. Does it seem sensible? Any ideas about how to perhaps put it under better testing? I'm having a hard time getting around the issue of actually forcing the selection from the diagram and or project explorer. I could do this with SWTBot, but we can't use that in our automated testing. I've tried simulating it by using monitor.handleWorkbenchPartSelection(editor, selection, true);  but that doesn't seem to do what I want.

Comment 11 Steffen Pingel 2011-09-22 14:44:53 EDT

> So given this, if a user selects an element in the diagram, it should a) mark
> the domain ("ecore") element as interesting, b) propagate up to parent package
> c) to parent "ecore" resource and then d) to workspace resource IFF that exists.

Sounds good to me.

> It won't propagate to the diagram file itself but that's fine, because the only
> way for the user to edit the diagram is to actually have it open in an editor.

The diagram file is the model for the presentation, right? As long as it gets some interest through the part selections (or whatever) that should be sufficient.
 
> This all works as outlined above. Does it seem sensible? Any ideas about how to
> perhaps put it under better testing? I'm having a hard time getting around the
> issue of actually forcing the selection from the diagram and or project
> explorer. I could do this with SWTBot, but we can't use that in our automated
> testing. 

I prefer not to but if it's the best approach to test the integrations we should consider it.

Comment 12 Miles Parker 2011-09-22 15:10:49 EDT

(In reply to comment #11)
> > It won't propagate to the diagram file itself but that's fine, because the
> only
> > way for the user to edit the diagram is to actually have it open in an editor.
> 
> The diagram file is the model for the presentation, right? As long as it gets
> some interest through the part selections (or whatever) that should be
> sufficient.

Yes "model for the presentation" captures it exactly. It's possible that for some kinds of GMF models we'll actually want to capture the presentation model as well, but I can't think of any good reasons to do that with the usages I've imagined. So just to be clear, the only interest for the diagram model will come from just what the resources ui would provide absent modeling bridge. But for the user it will look exactly the same. To see what I mean, look at an open .ecore and .ecorediag file in the project explorer. It seems to me that the propogation is working correctly but there might be some context features that I'm not aware of.

Comment 13 Miles Parker 2011-09-26 22:52:25 EDT

I'm marking this as closed. I've got the testing much more complete now as well since I've finally figured out how to mimic diagram selections, removals and additions pretty well.