Bugzilla – Full Text Bug Listing
| Summary: | Tons of errors after plug-in import | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Dani Megert <daniel_megert> | ||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, darin.eclipse, jarthana, Olivier_Thomann, remy.suen, tjwatson | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 3.7 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dani Megert
I followed the steps once with no problem, repeated step 5 and had no problems. Looking at code changes in CVS, I don't see any changes related to binary bundle import. The PDE team has been working on API tools. (In reply to comment #1) > repeated step 5 and had no problems. Sorry, repeated step 4. The second attempt had 3 errors: * API analysis aborted for 'org.eclipse.search' since its build path is incomplete org.eclipse.search line 0 Fatal Problem * The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.swt.graphics.Image. Fix the build path then try building this project org.eclipse.search Unknown Java Problem * The type org.eclipse.swt.graphics.Image cannot be resolved. It is indirectly referenced from required .class files SearchUI.java /org.eclipse.search/search/org/eclipse/search/ui line 1 Java Problem Following Dani's steps, I get no problems, but if I change the steps slightly I get a few problems (as shown above). Steps - note steps 2/3 are reversed: 1. start with new workspace 2. check out 'org.eclipse.search' from CVS 3. disable all plug-ins in the target 4. import all required bundles as binary projects Any ETA on this? I tried both Dani's steps and Darin's in I20100915-2024 and using the latest PDE code from HEAD. In all cases everything worked as expected. When the plug-ins weren't available, there were errors, when the plug-ins were available in the target or after importing, the errors go away. Also couldn't reproduce in I20100928-1200. There are no changes in the import code related to this. There have been few changes to PDE UI in general. > were available in the target There should always be none in the target as all have to be disabled in step 2. >I tried both Dani's steps and Darin's in I20100915-2024 Obviously it works in that build given I wrote in comment 0 that it still worked in N20100922-2000. >Also couldn't reproduce in I20100928-1200. I don't know whether everything from HEAD is in there but I just tried again EXACTLY following the steps from comment 0 against N20100928-2000: the first import (step 4) still worked but on the next import I got errors. In case you don't get the errors, repeat until you get the compile errors. On secondary import operations I sometimes get errors. When an error appears, it looks as though the plug-in classpath container is missing a couple entries (bundles). Closing/opening the project resolves the issue. Olivier, has anything changed recently with the timing or how Java classpath containers are resolved? We have case where the plug-in classpath container appears incomplete, but closing/re-opening the project fixes the problem. I am not aware of this. Jay, any idea ? The problem appears to be related to a change made in OSGi for bug 326011. In Tom's words: "in the resolver we used to automatically merge in any removal pendings for re-resolving when doing incremental resolves". The net effect is that not all bundles were removed from the state when doing an incremental resolve, and we ended up with stale bundle descriptions in the model. Tom has provided a patch which he will release to the I-build that restores the old behavior dor dev mode (PDE uses the state/resolver in dev mode). I'll take this one. It is related to changes in bug326011 In the fix to that bug I removed code that was aggressively flushing descriptions in the removal pending state. This is not something we want to do at runtime and I could not think of any reason to be this aggressive, so I removed the bit of code. I will revert the behavior for development mode (which is how PDE uses the resolver). Created attachment 180213 [details]
dev patch
I released the patch. Darin also entered bug326974 against PDE to discuss if PDE should be more explicit about resolving bundles which it has updated in the state instead of depending on auto flushing of removal pending descriptions. Verified in N20101004-2000. Thanks for fixing this! |