Community
Participate
Working Groups
Working set decorator does not change when contained resources change. We need to find a logical place to put the update handling for this. If one can't be found, then we can't decorate working sets.
Dirk, do you have ideas for this. The decoration code is not in the build yet but it would be nice if working sets that contain shared projects could be decorated. The problem is that a label change for the working set would need to be fired when any of it's contents changed. Would it be possible for the package explorer to do this?
Michael, this should be doable. Can we discuss this at EclipseCon since I would like to understand the implications better. Basically I need a listener on the working set model which catch label updates and propagates them up to the working set. To not update too often I somehow should be able to identify these events.
The ability to decorate ResourceMappings is not going to appear in 3.1. This bug does not need to be addressed until it does.
The code to decorate working sets has been released into 3.2. Working sets displayed in the package explorer are decorated but do not update when changes occur. I think the easiest fix is for the package explorer to update the decorations of a working set whenever the decoration for a direct child changes or when a direct child is added or removed. Moving to JDT to consider. Let me know if you can't do this for M1 so I can remove the working set decoration (i.e. I don't think we want them in for M1 if they do not update).
*** Bug 105077 has been marked as a duplicate of this bug. ***
I've had separate discussions with Dirk and Nick and it has become appearent that we need a general mechanism to handle this properly so I'm moving this back to Team. Dirk, if you can come up with something satisfactory for M1 that is not too much work than by all means do so but we'll need to solve this problem properly in M2 anyway. What came out of the discussions is that we need the following: 1) A mechanism to determine which model objects are affected by changes at the resource level and the ability to walk the parent chain of these model objects (i.e. to be able to fire label change events for all parent objects). This could be in the form of an extension point that uses and enablement rule to determine whi is interested in changes to particular projects and/or files (possibly similar to the refactoring participant extension points). 2) A mechanism to short curcuit the label changes if the state has not changed (i.e. redecoration of an entire parent chain may be expensive and should be avoided if the state has not changed).
Michael, I found out what causes the redecorating of the working set on every save. The root of this is the CVS label decorator which always refreshes the full parent chain on every save. This basically means that we recompute the error annotations for all parent elements. Although this might be fine yup to projects it will definitelly not scale for working sets which can have lots of projects as well. So I am a little reluctent to release my fix. So I opt for "commenting out" the label decoration code for working sets for M1. Regarding item one in comment #6: We have code that does exactly this. Every label change event that comes into a Java viewer where the elements are resources gets translated into a label change event that is Java element based.
Michael, what can we do to avoid sending out this fully parent chain on every save ?
It has to be done by CVS (or whoever provides the decorator). If CVS could walk the parent chain of the affected model objects, it could cache the previously calculated dirty state for each model object being decorated. Then it would only need to fire a label change and visit parents for objects for which the state has changed. We should be able to do this with resources today (but obviosuly don't as you have observered). We will need additional API to handle model objects that do not have a one-to-one mapping to resources (such as working sets).
Michael, as a first step could we optimize the existing code to not send out the label change events for the whole "resource based" parent chain if not necessary (e.g cache the state)?
Yes, that sounds like a gooding starting point.
Please let me know when this is in. I will then revive my patch to marks working sets as an interim solution until we have the model adapter story.
*** Bug 111200 has been marked as a duplicate of this bug. ***
I've released some support for this (see bug 121623 and bug 86159). Basically, the way it will work is this: - the model will determine the dirty state of it's model elements using the API mentioned in bug 86159 and decorate elements accordingly. It will be up to the model to propogate decorations as well. - the model will indicate to the repository decorator that they are handling the decoration using the API introduced in bug 121623. I still need a few more API pieces to make this work but I wanted to make you aware of what was happening.
I have released support for this into HEAD. I have logged bug 123978 against JDT/UI that describes how to ensure that working set decorations get updated.
*** Bug 114755 has been marked as a duplicate of this bug. ***
