Summary: | keeping the project references and required project in synch (1GL0L34) | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Erich Gamma <erich_gamma> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | dj.houghton, jeffmcaffer, martinae |
Version: | 2.0 | ||
Target Milestone: | 2.0 M1 | ||
Hardware: | All | ||
OS: | Windows 2000 | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 3308 |
Description
Erich Gamma
2001-10-10 22:55:04 EDT
*** Bug 3421 has been marked as a duplicate of this bug. *** The problem I am foreseing with making this a pure Core issue is that there are some circumstances where we will not be able to adjust the project references: when the classpath changes occurs outside the UI but rather from editing the .classpath file (or catching up with a distinct one). The setClasspath cannot edit the project description, because in this case it happens during a resource change notification (same issue we had in the past with remembering classpath as a project description attribute). The particular call of #setClasspath involved here is identifiable, and we could let it not change the project references, but introducing thus inconsistencies (not worse than currently). I think all comes down to the fact that the platform does not seem to provide any mechanism for a client to change a resource in reaction to a resource change. This sounds like a fair assumption, however when it comes to the project references, we cannot update these during a build, because the build order has already been computed, and the build would be wrong; and we cannot update them during a resource change notification because it is forbidden. We either need Core to allow changing project references during change notification, or provide a mechanism to notify clients at the end of a resource change notification operation (without passing the delta of course). Some kind of a final callback before resuming. Besides the regular read-only POST_CHANGE resource change listeners, Core allows users to register PRE_AUTO_BUILD and POST_AUTO_BUILD resource change listeners and these listeners are allowed to make changes to the workspace tree. Is this what you are looking for? One should be careful, though, as changing the project references automatically can produce undesired results for other plugins who have already set this value to be something else. Also note that changing the order of the project references may also change the build order. The problem is that once in a middle of a build, I would certainly not change the build order, it is already too late. So this is not an option for me. Now if the project references are not to be updated, how do you expect a change in a classpath to induce the proper build sequence ? This would defeat auto-building in correlation with VCM (see your bug report 3308). PRE_AUTO_BUILD notifications are doing the trick; even though it is really counter-intuitive. PRE_AUTO_BUILD is actually running even if not auto-building, it happens right beside the change, whereas the POST_CHANGE occurs after an optional build. Anyway, now the JavaCore sets project descriptions in place of the JUI, which makes it consistent VCM wise (where no UI is performing) and addresses bug 3308. But the way it does so is a problem. We should not be changing global project descriptions. What happens if multiple clients compete to do so ? A builder should be made responsible for producing a recommended build order, which would be merged by the platform to compute the actual one. *** Bug 3308 has been marked as a duplicate of this bug. *** Fixed |