Community
Participate
Working Groups
In the properties dialog of a file or folder, I can change the derived flag of the resource. This has implications on how repository providers will treat the resource. Unfortunately, changes in this flag are not included in Core deltas meaning that repository providers have no way of knowing about the change. In general, I don't think that including a derived flag change in a delta is appropriate as in most cases the flag change occurs at the same time the resource is created. However, the properites page is a special case where the derived flag is changed on an existing resource. Either the derived flag should not be modifiable in the properties page or modification of the flag in the properties page should generate a delta (i.e. the property page could do a touch on the resource).
Would touching the file suffice to give you the delta you need? There doesn't seem to be a resource delta flag for the derived state. Or would you always check on any resource delta? The derived state should probably be read-only anyway, since only processors like builders should be setting it.
Touching the resource at least will indicate that something changed. Since there is no flag in the delta to indicate that it is the derived flag that changed, it will be up to the repository provider to determine if the fact that the resource is derived or not is of significance. For CVS, we cache a dirty indicator for non-derived resources so we should be able to detect that the resource derived flag was changed.
I was about to file this bug myself. I can't pin it down at this point, but using "touch" to indicate a property change seems fraught with peril. I'd feel much more comfortable if there were a notification that specifically indicated that properties had changed.
Michael, is this still of interest?
It is still applicable but, given that it is rare for users to set the derived bit, I can't really claim it is all that interesting. Other people on the CC list may have a stronger feeling about it.
I added myself to the cc list, since I tried to implement a "derived resources" decorator, but found no way to keep it in sync when the flag changes. The APT team needs a way to flag generated resources in order to exclude them from java refactorings. One possible solution we came up with was to mark generated .java files as derived and to handle them specially (at least in JDT/UI, bug 111447). If we do follow this path, derived resources should be rendered specially, which is what I tried to do with a decorator.
With more and more .java files having the derived flag due to various model-driven tooling stacks, I think this issue is becoming more interesting (see bug 111447 for more details). Moving to core resources for comment on resource delta support for derived flag changes. If the derived flag could be specified when a resource is created, an extra notification would not need to be sent (see comment 0). How would doing a touch work? What does the delta look like for a touch? If this is not feasible, we can disable the option in the Properties dialog.
*** Bug 199260 has been marked as a duplicate of this bug. ***
Please put a comment on whether this enhancement would be be delivered, and if so , in which milestone. Thanks.
It's not in the plan yet, however we are ready for contributions. Are you considering working on this?
I'm trying to implement an "isDerived" filter for the common navigator and can't seem to overcome the lack of notification if the derived bit changes. It is admittedly a rare occurrence, but would be useful to have.
I think we could handle all resource attribute changes and send a delta for any attribute changes. IResourceDelta#ATTRIBUTE flag in IResourceDelta could indicate such a change.
Created attachment 147422 [details] Fix v01
Created attachment 147430 [details] Fix v01 & test
Why is the invocation of touch() added to setResourceAttributes? Is there a particular reason for omitting derived bit notification from builder deltas? A builder may be interested if a previous builder has altered the derived state of a resource. The additional issue here is that setDerived(boolean) now become potentially long-running because it requires locking the tree. Usually we make a change like this explicit by deprecating the method and adding setDerived(boolean, IProgressMonitor) so clients are made aware of this (did this for IFile#setCharset for example).
(In reply to comment #15) > Why is the invocation of touch() added to setResourceAttributes? By accident. I can't see this change in my workspace changes. > Is there a particular reason for omitting derived bit notification from builder > deltas? A builder may be interested if a previous builder has altered the > derived state of a resource. Right. I wasn't sure about builders. At first I wanted to provide a way to address the cases from comment 0 and comment 6. I can notify builders though. > The additional issue here is that setDerived(boolean) now become potentially > long-running because it requires locking the tree. Usually we make a change > like this explicit by deprecating the method and adding setDerived(boolean, > IProgressMonitor) so clients are made aware of this (did this for > IFile#setCharset for example). I used the same pattern that we have for setting markers. IResource#createMarker doesn't consume a progress. However we can go either way.
Created attachment 147562 [details] Fix v02 & test Some changes due to the recent comments.
Patch released to HEAD. I'll fix calls to deprecated API in Platform UI, JDT and PDE when I get API tooling report for the next N-Build. Moreover the migration guide will be updated.
Before we do this change we should measure build performance. I don't want JDT builds to take longer because more and/or bigger deltas are sent by the builder.
>because more and/or bigger deltas are sent ...and processed by all the listeners
The org.eclipse.jdt.core.tests.performance.FullSourceWorkspaceBuildTests suite doesn't indicate performance regression on my machine. However we would have to run the tests on our build servers to be absolutely sure.
I would expect the Java builder is only setting the derived bit on resources it is creating or modify in that build, so the element should already be present in the delta. Szymon, we also need a test of the resource delta for case where client sets the derived bit on creation using IFile#create(stream, IResource.DERIVED, pm) and same for IFolder.
(In reply to comment #22) > Szymon, we also need a test of the resource delta for case where client sets > the derived bit on creation using IFile#create(stream, IResource.DERIVED, pm) > and same for IFolder. Yes. I'll update the tests.
Please also add this to the 3.6 migration guide (/org.eclipse.platform.doc.isv/porting/3.6/recommended.html).
(In reply to comment #24) > Please also add this to the 3.6 migration guide > (/org.eclipse.platform.doc.isv/porting/3.6/recommended.html). I'll do it as stated in comment 18. I give some time for feedback from our teams before I announce it to the world.
Created attachment 147796 [details] Additional tests
The additional tests and the porting guide update released to HEAD.
>the porting guide update released to HEAD. As is, the guide does not appear. I've update the doc to show a 3.6 porting guide.
Marking FIXED.
