Bugzilla – Full Text Bug Listing
| Summary: | [modeling] Update DoI model elements on Model Property Changes | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Benjamin Muskalla <b.muskalla> |
| Component: | Mylyn | Assignee: | Miles Parker <milesparker> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 351889 | ||
|
Description
Benjamin Muskalla
re: Refactorings, My thinking is not. :) EMF Refactoring support is still early incubation, and refactoring plays much less of a part in model development. In a sense with a model much of what we think of as refactoring (entity renaming, moving, etc..) is "built-in" in that there is always one and only one place to change it. One thought on all of this is that we might want to actually hook into the EMF change notification mechanism itself. That would give us much finer grained access than would just listenting to selection events. That will be a lot trickier to implement, but on the other hand it means that we might end up with a generic way of dealing with not just EMF (meta-model level) model editors but EMF generated editors as well. *That* would be cool. We should discuss the availability for EMF generated editors anyways. Otherwise, is EMF Refactoring really to right approach to rely on? My thinking is that they provide the refactoring while we're essentially interested in change deltas of the artifacts (if due to a merge, refactoring or simple attribute change). (In reply to comment #2) > We should discuss the availability for EMF generated editors anyways. > > Otherwise, is EMF Refactoring really to right approach to rely on? My thinking > is that they provide the refactoring while we're essentially interested in > change deltas of the artifacts (if due to a merge, refactoring or simple > attribute change). Exactly. Though I wasn't thinking of external change delta, I was only thinking of internal editor changes. I'm not sure we have to worry about these issues at all. In Mylyn do you keep degree of interest scores across refactorings, even when those refactorings occur as a result of external changes. (Actually I'm not sure how you would be able to do this.) For example, if you've been working on a method, and then you do a merge against master where someone else has renamed that method, would you retain the DOI for that? Otherwise, if we simply have auniqu path to stuff people are interested, isn't that enough? It's either: 1. Added in which case we couldn't have been interested in it. 2. Modified in which case the same element mapping would work. 3. Deleted in which case we shouldn't find it. :) 4. Had its name changed in which case wouldn't it be ok to ignore it? Yes, for the interaction events, we only want to see the selections and changes in the editor.
> 4. Had its name changed in which case wouldn't it be ok to ignore it?
This is how the current JDT bridge is implemented. The idea here would be to improve this situation (maybe this even needs changes to the context framework). The tracking of changes from other sources (eg. EMF refactoring) would be interesting for to "transform" the context the next time you activate the context (eg. based on the refactoring history).
OK, I'm going to change the summary of this one on the basis that refactoring support will be out of scope for this effort. Benny, perhaps open another more general bug on Context for that idea? We'll focus on selection events here. I think the change notification stuff might be interesting to look at later, especially if we do DSL / text-absed integration, but it would be challenging to impossible to get selection events form that anyway. So this task now just relates to property editor interactions. See related refactoring tasks: task 344166: Rename package refactoring doesn't update Mylyn task contexts task 346352: Extract method refactoring should add the newly created method to the context task 344166: Rename package refactoring doesn't update Mylyn task contexts (This one is also essentially complete.) Correction. We will not be doing support for properties. See bug 343201. So I'm marking this one "wont' fix". If anyone has a good reason they want this, please speak up! Reorganizing. |