Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 327544 - Project#hasNature returns false during project open event, even though project does have nature
Summary: Project#hasNature returns false during project open event, even though projec...
Status: RESOLVED NOT_ECLIPSE
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.7   Edit
Hardware: PC Linux-GTK
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-12 07:41 EDT by James Blackburn CLA
Modified: 2010-10-12 08:30 EDT (History)
0 users

See Also:


Attachments
backtraces (3.97 KB, text/plain)
2010-10-12 08:16 EDT, James Blackburn CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Blackburn CLA 2010-10-12 07:41:11 EDT
CDT has a listener which responds to project open, and does:

project.isOpen() ? project.hasNature(CProjectNature.C_NATURE_ID) : true;

However I'm seeing hasNature(org.eclipse.cdt.core.cnature) return false -- natureIDs == String[0].  This is during a project set import.  When the breakpoint is set in hasNature, looking on disk at the .project shows:
<natures>
     <nature>org.eclipse.cdt.core.cnature</nature>
     <nature>org.eclipse.cdt.managedbuilder.core.managedBuildNature</nature>
     <nature>org.eclipse.cdt.managedbuilder.core.ScannerConfigNature</nature>
</natures>


Backtrace looks something like:

ProjectDescription.hasNature(String) line: 241	
Project.hasNature(String) line: 539	
ResourceChangeHandler2(ResourceChangeHandlerBase).shouldVisit(IProject) line: 166	
ResourceChangeHandlerBase$DeltaVisitor.visit(IResourceDelta) line: 101	
ResourceDelta.accept(IResourceDeltaVisitor, int) line: 68	
ResourceDelta.accept(IResourceDeltaVisitor, int) line: 79	
ResourceDelta.accept(IResourceDeltaVisitor) line: 48	
ResourceChangeHandler2(ResourceChangeHandlerBase).doHandleResourceMove(IResourceChangeEvent, ResourceChangeHandlerBase$IResourceMoveHandler) line: 201	
ResourceChangeHandler2(ResourceChangeHandlerBase).resourceChanged(IResourceChangeEvent) line: 160	
ResourceChangeHandler2.resourceChanged(IResourceChangeEvent) line: 175	
NotificationManager$2.run() line: 291	
SafeRunner.run(ISafeRunnable) line: 42	
NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 285	
NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 149	
Workspace.broadcastPostChange() line: 346	
Workspace.endOperation(ISchedulingRule, boolean, IProgressMonitor) line: 1394	
Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2255	
NotificationManager$NotifyJob.run(IProgressMonitor) line: 40	
Worker.run() line: 54
Comment 1 James Blackburn CLA 2010-10-12 08:16:46 EDT
Created attachment 180661 [details]
backtraces

So I set two breakpoints:
  - One in our project-open resource change handler  (1)
  - One in ProjectDescriptionReader#endNaturesElement. (2)

When this bug occurs breakpoint (1) is hit before breakpoint (2) due to the notification manager's asynchronous notification.  
This is pretty bad, as AFAICS, the project description hasn't been loaded, but resource change listeners have been notified that the project is accessible.
Comment 2 James Blackburn CLA 2010-10-12 08:23:41 EDT
Subclipse creates and opens the project, then populates it. This seems like a bad thing to do.  Will file a bug there, and in the interim check for delta in the project description.
Comment 3 James Blackburn CLA 2010-10-12 08:30:49 EDT
http://subclipse.tigris.org/issues/show_bug.cgi?id=1201