Community
Participate
Working Groups
Source code based, v_770. Noticed that at BatchImageBuilder#101-110 we marked resources as derived before deleting them, which seemed sub-optimal to me (argument being that it is worthless to modify a resource you're about to delete). Discussed the point with Kent, who told me that the intent here is to make sure that delete deltas generated by the subsequent delete are properly marked as concerning derived resources. Since we 'own' output folders in this case (see surrounding test of the compiler option), the argument is that the resources we delete there *must* be derived, at least when they are seen from the listeners who get the delete delta. I've pondered a bit on this since and I still see a couple of problems with the approach: - it is not thread-safe; while the window of opportunity is short, another thread could still change the derived flag on the resource; this is admittedly very unlikely, but, this would still raise the question about another thread producing new files while we are deleting the output folder contents; the question here is: would there be other means to express the 'JDT owns the output folders' statement, in a way that would be more proactive and cost effective? else, would it be possible to ensure proper transactional properties on the delete action? - the case of source folders that are also output folders is not handled consistently with the case of a dedicated output folder per source folder: line 136, we merely delete whatever file that is named as a class file without enforcing it to be marked as derived, which could lead to delete deltas without the derived mark if I get it well (provided that someone else dumps files that have class file names but are not marked as derived). Opened this bug to keep the discussion flowing.
1. No other job in Eclipse can manipulate resources while a build is running and the derived flag is a resource based flag. If another tool outside of Eclipse adds more .class files, then these files appear after the next refresh operation and will be seen by the next build. We're checking the status of the 'derived' flag only to ensure that additional .class files, which can be added to the output folder by other tools, are tagged appropriately. All .class files generated by our builder will be tagged so its only additional files that may need to be tagged, so the performance concern should only surface in the case where numerous additional .class files have been added. 2. Addressed the second point by adding a new check to ensure .class files in a source folder are also tagged as derived.
Created attachment 79657 [details] Proposed patch
Code verified for 3.4M3 using I20071029-0010 build.
