Community
Participate
Working Groups
I’m not sure if this is a PDE or JDT bug. Basically, after updating source code, the workspace is in a state where some projects don’t compile because of a missing dependency (plugin project) and that’s fine. After importing the new project and refresh/clean all, it doesn’t fix the errors. I’ve been trying to make a standalone example but I haven’t succeeded yet. But I have managed to reproduce it 100% of the time with CDT code: Setup: Eclipse 4.4 I20140526-2000 API Tools Execution Environment Descriptions 1.0.1.v20140424-1723 Using repo git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git 1. Checkout 0f6719cc7184360281e3aed236c7b8cb7c4466af 2. Import and build: - cdt.core - cdt.core.aix - cdt.core.linux - cdt.core.macosx - cdt.core.qnx - cdt.core.solaris - cdt.core.win32 There should be no error (ignore missing baseline errors) 3. Checkout 2b9bbdec613af66f1d7ab99d0221067438c79bd7 4. Refresh and Clean All 5. The expected errors appear, like: - Bundle 'org.eclipse.cdt.core.native' cannot be resolved - IProcessInfo cannot be resolved to a type 6. Import cdt.core.native 7. Refresh and Clean all. 8. A lot of errors persist but they are false positives: - IProcessInfo cannot be resolved to a type 9. Restart Eclipse. Refresh and Clean all -> Errors disappear. I’ve also seen this bug happen multiple times while working on Linux Tools code.
(In reply to Marc-Andre Laperle from comment #0) > 5. The expected errors appear, like: > - Bundle 'org.eclipse.cdt.core.native' cannot be resolved > - IProcessInfo cannot be resolved to a type > 6. Import cdt.core.native What do you mean by import here? Bring in from source control into the workspace? Add to your target platform? Change the dependencies in a manifest.mf? > 7. Refresh and Clean all. > 8. A lot of errors persist but they are false positives: > - IProcessInfo cannot be resolved to a type At this point, is cdt.core.native on the classpath (under the Plug-in Dependencies classpath container)?
Thanks for your help Curtis. (In reply to Curtis Windatt from comment #1) > What do you mean by import here? Bring in from source control into the > workspace? Add to your target platform? Change the dependencies in a > manifest.mf? Bring in from source control into the workspace. I used git from the command line to checkout the revision and imported the project with the regular project import wizard, just to make sure EGit is not interfering. > > 7. Refresh and Clean all. > > 8. A lot of errors persist but they are false positives: > > - IProcessInfo cannot be resolved to a type > > At this point, is cdt.core.native on the classpath (under the Plug-in > Dependencies classpath container)? That's interesting, there is actually no Plug-in Dependencies classpath container under the projects containing the errors. After restarting, then the containers appeared.
Created attachment 243704 [details] Test projects OK, I have a better handle on what’s going on in this scenario. The updating of the classpath relies on bundle deltas. Normally, if a missing dependency gets added, the bundle with the previously missing dependency becomes RESOLVED and generates a corresponding delta which in turn updates the classpath. But in the case of fragments, if the platform filter doesn’t match the environement, it is not resolved and therefore it doesn’t generate deltas. The only ways it updates its classpath is when it’s added to the workspace (closing/reopening the project) or when it’s modified (modifying the manifest.mf). I made test projects to illustrate this behavior: - testfragment - testplugin - testpluginOther 1. Import testfragment first. Errors are generated, that’s OK. 2. Import testplugin (the host plugin). The classpath is not updated for testfragment. 3. Import testpluginOther (a dependency for testFragment). The classpath is still not updated for testfragment. 4. Clean all. The classpath is unchanged. One thing I tried was to update all fragments classpaths for a host plugin that had its classpath updated but that’s not sufficient because fragments can have their own dependencies independent of the host plugin so there wouldn’t be a delta generated for the host plugin. So I made a heavy handed patch that updates all the fragments classpaths, but that can’t be good for performance. Any suggestions? Patch: https://git.eclipse.org/r/27566
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
