Bug 478051 - error marker, package decorator and problems view table out of sync
Summary: error marker, package decorator and problems view table out of sync
Status: NEW
Alias: None
Product: AJDT
Classification: Tools
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: AJDT-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-22 07:24 EDT by Joerg Buchberger CLA
Modified: 2015-09-30 04:36 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Buchberger CLA 2015-09-22 07:24:29 EDT
when we remove a method from an abstract class with several abstract base classes

other classes calling that method are neither marked in package explorer, nor are their errors shown in the problems view, however, opening such a class will at least underline the call as error

only upon full clean build do package explorer and problems view pick up the errors

it also fails the other way around - upon reverting the change,
package explorer and problems view still show errors

it is disturbing that existing methods are reported as undefined and vice versa
Comment 1 Stephan Herrmann CLA 2015-09-22 09:26:57 EDT
Is "Build Automatically" enabled?

Does it happen between classes of the same project or only if project dependencies are involved? If the latter, what dependency management is used (plain Java projects? Maven? PDE?).
Comment 2 Joerg Buchberger CLA 2015-09-22 11:21:25 EDT
Yes, "Build Automatically" is enabled - we deliberately have put it in the Oomph setup, so it gets enabled on every Eclipse startup if it happened to be disabled manually.

Workspace preference is refresh on access, however, refreshing using native hooks does not make any difference either.

Hmm, I'm not sure, whether it only happens cross project boundaries. I'll have to check this more thoroughly before I can give a definite answer. What I can tell, is that I observed it happening cross plugin project boundaries.

Most of our projects have PluginNature, i.e. they are OSGi bundles built by PDE.
Only few are plain Java projects. I'll have to check, whether they can get affected, too.
Comment 3 Joerg Buchberger CLA 2015-09-22 11:37:33 EDT
For the calling class it, does not make any difference, whether it is located in a plain Java or a PDE plugin project. The other way around, naturally does not apply anyway, i.e. we never consume methods defined in our plain Java projects from within the plugin projects.

Furthermore, I can confirm, that this issue happens cross project boundaries only, i.e. callers inside same project are always in sync immediately.

Ok, and I've to correct myself - a full clean is not needed. It's good enough to clean affected projects. Cleaning a single affected project will only put that single project in sync.
Comment 4 Stephan Herrmann CLA 2015-09-24 08:23:58 EDT
Moving to PDE for comments, since apparently we have trouble with change notification across a PDE based classpath either getting out of sync or not sending necessary deltas (or those deltas not getting processed by JDT).

@Vikas, have you heard of / seen issues like this before?

@Joerg: thanks for the info so far. More questions:
Does the Error log contain any entries from the time when the problem occurs?
Are other plugins active that could possibly modify content in output folder (bin/ or such)? E.g., more builders in addition to JDT and PDE?
Comment 5 Joerg Buchberger CLA 2015-09-24 10:48:49 EDT
@Stephan: Thanks for addressing. Your questions are catalytic ;-)

There are no entries in the errors log around the time, when I reproduced this.

However, the central project related to this issue has an AspectJ nature + builder active:
- org.eclipse.ajdt.core.ajbuilder
- org.eclipse.ajdt.ui.ajnature

When I remove the aspectJ capability, the issue cannot be reproduced anymore.
Even after re-enabling it later. Note, though, that our whole team was affected by this, so I think it definitely was not some sort of random Heisenbug. And I somewhat expect it to maybe come back later ...

Please, also note that another team member was able to workaround this issue by refactoring said abstract class into a concrete base class.
Comment 6 Stephan Herrmann CLA 2015-09-24 10:53:16 EDT
On to AJDT then :)

I'm sure the AspectJ builder needs to participate in determining what needs rebuilding when, so there might be a bug in that part?
Comment 7 Joerg Buchberger CLA 2015-09-25 12:18:34 EDT
maybe a duplicate of bug 405299
Comment 8 Joerg Buchberger CLA 2015-09-25 12:19:50 EDT
possibly related forum thread:
https://www.eclipse.org/forums/index.php/m/898891/?srch=error+marker#msg_898891