Community
Participate
Working Groups
I20061214-1445 (3.3M4), same in HEAD Steps in M4: - new workspace - create new Java Project - add this line to .classpath and save: <classpathentry kind="var" path="JUNIT_HOME/junit.jarXXX"/> => Build path error marker is generated: "Project J is missing required library: 'C:\e\i\I20061214-1445-clean\plugins\org.junit_3.8.2\junit.jarXXX'" - project properties > Java Compiler > Building - enable project specific settings - set "Incomplete build path:" to Warning - OK - Yes (do a rebuild) => Marker has still Error severity, even after Project > Clean Expected: severity should change to Warning - close project and reopen => Marker has correct severity now I realized this when I tested Frederic's fix for bug 172207 via hot code replace. Users may find it hard to find out what's wrong when Clean does not clean everything. Bug 159452 and/or bug 154479 could be related.
Reproduced with I20070130-0800.
Released inactive test cases BuildpathTests#_testMissingLibrary3 and 4.
Created attachment 58245 [details] Fixed, non definitive test cases This patch fixes the test cases added to BuildpathTests so that they pass without changing the code. However, I believe this is not what we want to do (see further discussion below).
Frédéric, I believe that DeltaProcessor#validateClasspaths should detect that a change to <project>/.settings/org.eclipse.jdt.core.prefs may imply changes to the classpath and generate appropriate deltas, as it does when finding a change to .classpath (DeltaProcessor:2183 in head). Beware that it currently cuts the recursion upon .settings itself.
Created attachment 58674 [details] Proposed patch I have included Maxime's tests and they pass with this patch. Jerome, what's your mind about this fix?
All JDT/Core Builder and Model tests also pass with this patch. Of course, scenario described in comment 0 also passes with it... :-) Note that with this change, DeltaProcessor will validate the classpath each time the compiler settings is modified. Perhaps, one can perform a more fine grain refresh while adding preference change listeners to JavaProject and only react on build preferences changes... I'll investigate this point and try to see if it's feasible.
There's already preferences listeners on JavaCore and JavaProject. However, as they both do not know the DeltaProcessingState, there's no easy way to validate classpath from there. So, the proposed fix is the best I can see for now. Note also that it will also fix bug 75471...
(In reply to comment #7) > Note also that it will also fix bug 75471... > Added test case (see bug 75471 comment 10) shows that this assumption was wrong...
Released for 3.3 M6 in HEAD stream.
*** Bug 92614 has been marked as a duplicate of this bug. ***
Reopen this bug for 2 reasons: 1) Some tests added in BuildpathTests failed in integration build I20070220-0800 2) The fix does not work when workspace preferences are changed...
Created attachment 59863 [details] Additional patch to fix problem with workspace preferences I also did not see any new failures while looking at nightly builds tests log. So, I consider the tests problem also fixed, but still keep them as safe for a while to be 100% sure of this...
Additional patch released for 3.3 M6 in HEAD stream.
Verified for 3.3 M6 using build I20070320-0010
