Community
Participate
Working Groups
EG (03.10.2001 11:40:48) the code to keep the required project on the java build path and the referenced projects in synch is in the UI. It should be pushed down to JCORE so that people using the API get the same behaviour. It got requested on EC today. Here is the posting: ------ It seems that classpath entries between projects must always be coupled with referenced projects. That is, if project A has a classpath entry pointing to project B, then A must also list B as one of its referenced projects so the builds will fire in the correct order. When this is not true, multi-project builds run in an unspecified order and A might build before B. Therefore the method JavaProject.setRawClasspath() should do this update automatically. A user of this API will not know about the above restriction and will have to figure it out when projects don't build in the right order. ------ NOTES: PM (10/4/2001 12:02:02 PM) Makes sense. However, how do we deal with conflicts ? Do we override defaults ? Doesn't this come back to have the JavaCore compute the build order of Java projects ? PM (10/8/2001 12:18:17 PM) Code from EG: /** * @param jproject The Java project after changing the class path * @param prevRequiredProjects The required projects before changing the class path */ private static void updateReferencedProjects(IJavaProject jproject, String[] prevRequiredProjects, IProgressMonitor monitor) throws CoreException { String[] newRequiredProjects= jproject.getRequiredProjectNames(); ArrayList prevEntries= new ArrayList(Arrays.asList(prevRequiredProjects)); ArrayList newEntries= new ArrayList(Arrays.asList(newRequiredProjects)); IProject proj= jproject.getProject(); IProjectDescription projDesc= proj.getDescription(); ArrayList newRefs= new ArrayList(); IProject[] referencedProjects= projDesc.getReferencedProjects(); for (int i= 0; i < referencedProjects.length; i++) { String curr= referencedProjects[i].getName(); if (newEntries.remove(curr) || !prevEntries.contains(curr)) { newRefs.add(referencedProjects[i]); } } IWorkspaceRoot root= proj.getWorkspace().getRoot(); for (int i= 0; i < newEntries.size(); i++) { String curr= (String) newEntries.get(i); newRefs.add(root.getProject(curr)); } projDesc.setReferencedProjects((IProject[]) newRefs.toArray(new IProject[newRefs.size()])); proj.setDescription(projDesc, monitor); }
*** 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
