Community
Participate
Working Groups
Build: F2 but using the latest org.eclipse.pde.ui and org.eclipse.pde.core builds. 1. Start a new runtime instance with a fresh workspace. 2. Go to the Target Platform preference page, select all plugins except org.eclipse.ui and org.eclipse.ui.win32 (This is so that we don't run into the problem described in defect 16683). 3. Switch to the PDE perspective. Import the two plugins org.eclipse.ui and org.eclipse.ui.win32 into your workspace. They will import successfully but with errors, because the classpath at that point is incomplete. These errors will go away when you explicitly update your classpath. 4. Update the classpath of these two plugin projects. Here comes the interesting part: 5. Try to re-import those two plugins. Click Yes when asked to overwrite the plugins in your workspace. When the operation is complete, a very bizzarre thing happens: i. The plugin projects imported are NOT seen in the PDE perspective, indicating that they are not plug-in projects. You will still see compilation problems in the Tasks view. ii. Switch to the resource perspective. They are there. The .project files indicate that they have the PDE project nature. So how come they disappeared from the PDE perspective.
Confirmed but I have no idea why. Moving to JDT UI - these two projects have a valid Java nature and should appear in Packages. Revised steps to recreate: 1. Start a new runtime instance with a fresh workspace. 2. Go to the Target Platform preference page, press 'Select All'. 3. Import org.eclipse.ui and org.eclipse.ui.win32 using the Import Plug-ins wizard. This will cause errors, because the classpath at that point is incomplete. 4. Update the classpath of these two plugin projects using 'Update Classpath...' action. Here comes the interesting part: 5. Try to re-import those two plugins. Click Yes when asked to overwrite the plugins in your workspace. When the operation is complete, a very bizzarre thing happens: i. The plugin projects imported are NOT seen in the PDE perspective, indicating that they are not plug-in projects. You will still see compilation problems in the Tasks view. ii. Switch to the resource perspective. They are there. The .project files indicate that they have Java nature. The decorator indicates that they are binary, which is OK. They should show up in Packages. Toggling 'Binary projects' filter on and off does not help.
The original description talks about the navigator. Have to verify that this is a JDT/UI problem. If so it is a candiate for F4
JDT CORE has put in a fix related to Java natures of projects. I suspect that this bug is covered by this fix. Dirk pls test again on F3
Problem still exists on F3 (following steps described by Dejan). Tried to bring the two projects back by - pressing F5 to refresh view - creating a new Java Project - closing and reopening the Package Explorer - opening Java Perspective Nothing helped. Since close the Package Explorer and reopening it rereads the Java Model I assume that the projects got somehow lost in the Java Model. Moving to JDT/Core for investigation.
Problem in the DeltaProcessor: when the project is removed, it is removed from the JavaModel in the PRE_DELETING event. Then it is added and its description is changed: we have a CHANGED resource delta for this project where the description is changed. In this case, we don't add the project back to the JavaModel as we do if another change to the project is done.
Propose fix: /* * Process the given delta and look for projects being added, opened, closed or * with a java nature being added or removed. * Note that projects being deleted are checked in deleting(IProject). * In all cases, add the project's dependents to the list of projects to update * so that the classpath related markers can be updated. */ public void checkProjectsBeingAddedOrRemoved(IResourceDelta delta) { IResource resource = delta.getResource(); switch (resource.getType()) { case IResource.ROOT : // workaround for bug 15168 circular errors not reported if (this.manager.javaProjectsCache == null) { try { this.manager.javaProjectsCache = this.manager.getJavaModel().getJavaProjects(); } catch (JavaModelException e) { } } IResourceDelta[] children = delta.getAffectedChildren(); for (int i = 0, length = children.length; i < length; i++) { this.checkProjectsBeingAddedOrRemoved (children[i]); } break; case IResource.PROJECT : // NB: No need to check project's nature as if the project is not a java project: // - if the project is added or changed this is a noop for projectsBeingDeleted // - if the project is closed, it has already lost its java nature int deltaKind = delta.getKind(); if (deltaKind == IResourceDelta.ADDED) { // remember project and its dependents IProject project = (IProject)resource; this.addToProjectsToUpdateWithDependents (project); // workaround for bug 15168 circular errors not reported if (this.hasJavaNature(project)) { this.addToParentInfo ((JavaProject)JavaCore.create(project)); } } else if (deltaKind == IResourceDelta.CHANGED) { IProject project = (IProject)resource; if ((delta.getFlags() & IResourceDelta.OPEN) != 0) { // project opened or closed: remember project and its dependents this.addToProjectsToUpdateWithDependents(project); // workaround for bug 15168 circular errors not reported if (project.isOpen()) { if (this.hasJavaNature (project)) { this.addToParentInfo((JavaProject)JavaCore.create(project)); } } else { JavaProject javaProject = (JavaProject)this.manager.getJavaModel().findJavaProject(project); if (javaProject != null) { try { javaProject.close(); } catch (JavaModelException e) { } this.removeFromParentInfo(javaProject); } } } else if ((delta.getFlags() & IResourceDelta.DESCRIPTION) != 0) { boolean wasJavaProject = this.manager.getJavaModel().findJavaProject(project) != null; boolean isJavaProject = this.hasJavaNature(project); if (wasJavaProject != isJavaProject) { // java nature added or removed: remember project and its dependents this.addToProjectsToUpdateWithDependents(project); // workaround for bug 15168 circular errors not reported if (isJavaProject) { this.addToParentInfo((JavaProject)JavaCore.create(project)); } else { JavaProject javaProject = (JavaProject)JavaCore.create(project); try { javaProject.close(); } catch (JavaModelException e) { } this.removeFromParentInfo(javaProject); } } else { // in case the project was removed then added then changed (see bug 19799) if (this.hasJavaNature (project)) { // need nature check - 18698 this.addToParentInfo((JavaProject)JavaCore.create(project)); } } } else { // workaround for bug 15168 circular errors not reported // in case the project was removed then added then changed if (this.hasJavaNature (project)) { // need nature check - 18698 this.addToParentInfo ((JavaProject)JavaCore.create(project)); } } } break; } }
Fix looks good. For F4, we solved a couple corner cases where JavaModel would become inconsistent and promote/loose Java project intempestively. This one is just another scenario. Consequences of the bug are quite severe, fix is quite simple. There was one scenario where the Java project would not be added back to the model, and it is mostly visible through the PDE scenario (where a PRE_DELETE event occurs before). Should fix for F4
Changing target milestone from M4 to F4.
Yes, fix is simple and prevents projects from disapearing from Package Explorer. Without this fix, user has to exit and restart the workspace to see the projects in the Package Explorer. I also think this should be fixed for F4.
Verified.
Fix got approved, released in 20020620.
*** Bug 20643 has been marked as a duplicate of this bug. ***
