Bug 50207 - Compile errors fixed by 'refresh' do not reset problem list or package explorer error states
Summary: Compile errors fixed by 'refresh' do not reset problem list or package explor...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M7   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 50209 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-19 08:08 EST by Ian Brown CLA
Modified: 2004-02-12 13:29 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Brown CLA 2004-01-19 08:08:35 EST
When you have a project that also references external jars, there appears to 
be a problem with error tagging.

Consider the following example:

I have a project that has some code that references external jars.

In the first instance, there were missing methods in classes in the external 
jars, so the compile failed. The open editor displayed the errors, as did the 
Package Explorer and the Problems view.

I replaced the external jar with one that fixed the errors, and did a 
Project 'refresh' from the package explorer.

The rebuild occurred and, in the open editor, all indications of the error 
state disappeared.

However, the Problems view still displays all of the original compilation 
problems (now resolved), and the Package Explorer still has a red 'x' next to 
the class and package that had the problems.

Doing a "rebuild all" correctly resets the state of the Package Explorer and 
Problems view.

It would seem that the build done by the 'refresh' does not clear the error 
states in the views before performing the compilation.
Comment 1 Ian Brown CLA 2004-01-19 08:12:18 EST
NB This was observed with build N200401150010, but I couldn't say it was 
restricted to just that version
Comment 2 Philipe Mulet CLA 2004-01-19 09:20:08 EST
Feels like no build is actually occurring since no resource got touched (only 
external JARs). Wondering if we should force to touch project (as we do when 
touching a cp variable/container).
Comment 3 Philipe Mulet CLA 2004-01-19 09:34:47 EST
*** Bug 50209 has been marked as a duplicate of this bug. ***
Comment 4 Jerome Lanneluc CLA 2004-01-23 04:45:12 EST
Fixed by touching the project when the delta processor detects an external jar 
change during refresh.

Added regression test BuildPathTests.testExternalJarChange()
Comment 5 David Audel CLA 2004-02-12 13:29:36 EST
Verified for 3.0M7