Summary: | Double entries on Java project properties | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | DJ Houghton <dj.houghton> |
Component: | UI | Assignee: | Simon Arsenault <simon_arsenault> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P1 | CC: | dirk_baeumer, fillg1, martinae, n.a.edgar, peter_burka, philippe_mulet |
Version: | 2.0 | ||
Target Milestone: | 2.0 F4 | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
DJ Houghton
2002-06-12 19:08:52 EDT
Couldn't reproduce under Window 2000/English version. Did the following: - create fresh workspace - started Eclipse - open Java perspective - create new Java Project "Test" - opened properties dialog There is only one page for "Java Build Path" and "Javadoc Location" This only happens in the following scenario: - open on fresh workspace - create Java project using the new wizard with loading Java plugin - select project in navigator - open properties observe: you see the described behaviour - open Package Explorer - open properties observe: you see the described behaviour More preceise the behaviour only happens when - it depends on from which view (Naviagtor or packages View) the properties dialog is opened first. - create a workspace with a Java project - close workspace with active package explorer - open workspace - select project in package explorer - open properties observe: the look ok - select project in naviagtor and open properties observe: the look ok - close workspace with active Navigator - open workspace - select the project - open properties observe: you see the described behaviour - select project in package explorer observe: you see the described behaviour JDT-UI is contributing to Build Path and two Java Doc location pages one for a IProject and one for a IJavaProject. ==== Code from plugin.xml ======================================= <page name="%buildPathPageName" id="org.eclipse.jdt.ui.propertyPages.BuildPathsPropertyPage" objectClass="org.eclipse.core.resources.IProject" class="org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage"> <filter name="nature" value="org.eclipse.jdt.core.javanature"/> </page> <page name="%buildPathPageName" id="org.eclipse.jdt.ui.propertyPages.BuildPathsPropertyPage" objectClass="org.eclipse.jdt.core.IJavaProject" class="org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage"> <filter name="nature" value="org.eclipse.jdt.core.javanature"/> </page> ======================================================= But the two contributions are in the JDT-UI plugin.xml since a very long time (checked build 20020430). So the bug either exists since a long time or this is a regression/bug in workbench or core. Just did the following: - get project properties for org.eclipse.ui in Navigator - does not have Java Build Path or Javadoc Location pages - get project properties for org.eclipse.ui in Packages view - it does have them Candidate for F4. I tested this and can reproduce the two problems (no entries in prop from nav view or double entries in prop from package view). We would not see this problem if the XML only had one entry and was marked as adaptable (i.e. keep the one for IProject and mark it as adaptable, remove the entry for IJavaProject). But what is in the XML is not wrong and should be supported by the workbench. Even if the XML was changed, there would still be a major problem with the workbench code. We should not be caching the adaptable contribution results in the same cache as the regular object contribution results. *** Bug 20141 has been marked as a duplicate of this bug. *** What is the risk of the proposed fix? The risk is low. The code changes are all internal. I've made the changes in my environment and it fixes all the reported problems. I've not seen other problems show up because of it. *** Bug 20324 has been marked as a duplicate of this bug. *** *** Bug 20433 has been marked as a duplicate of this bug. *** Made the changes to ObjectContributorManager to maintain two cache - one for regular object class contributors, and the other for object resource adapter class contributors. Code was checked by Tod and Nick |