Bugzilla – Full Text Bug Listing
| Summary: | Plug-in Dependencies not properly adjusted when fragment project opened/closed | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | C. Lamont Gilbert <clg-business> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | Karice_McIntyre, tjwatson, wassim.melhem |
| Version: | 3.1 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 109383 | ||
|
Description
C. Lamont Gilbert
Upon further evaluation its not merely swt. The fragment can not see any of the parent's classes nor the ones the parent is dependent upon until I touch the parents manifest. I put it at major because it has taken me several days to find this workaround. Until the workaround is discovered this is a blocker. Additionally, all my projects have linked output folders. Additionally there is an issue with dependent plugins as well. Project A is a plugin project. Project B is also a plugin project. Project B imports project A. When project B is closed, project A complains. Project A=WAD2, Project B=WAD2_JDOCore2. This is what I get. Please excuse formatting as this is cut and paste from Problem list; Severity Description Resource In Folder Location Creation Time 2 Project WAD2 is missing required Java project: 'WAD2_JDOCore2' WAD2 September 15, 2005 9:03:14 AM Severity Description Resource In Folder Location Creation Time 2 The project cannot be built until build path errors are resolved WAD2 September 15, 2005 9:03:14 AM Same solution. Touch and save project A's manifest and all is well. Again I have multiple project B's and this happens with all of them. Bump! Dont you folks think this is pretty nasty bug? Its probably leaving some folks thinking the thing does not work. Especially people new to eclipse. I 1/2 expected the bug to be marked as a dupe and im surprised i havent seen any other reports of this. Wonder if its my linked folders? Also, why is this marked as UI bug? Anyway, I know everyone is busy. I would dig into it but I just started using osgi stuff in my projects... I figured out what is happening. I have a project structure like so WAD - main plugin dependent on: WADInterface WADInterface - plugin WADDJO - plugin dependent on: WADDS, WADInterface WADJDOGUI - fragment of WAD dependent on: WADJDO, WADDS WADDS - plugin dependent on: WADInterface This is what happens. 1. open Interface 2. Open WAD plugin 3. Open WADDS plugin 4. Open WADJDO plugin 5. Open WADGUI fragment complains about not finding classes 6. Touch WAD manifest This causes the dependencies of WADGUI to be attached as dependencies of WAD and WADGUI stops complaining. so it seems as if fragments get all their dependencies through the plugin, even the ones they claim to import themselves are actually attached to the plugin they frag, and imported that way. 7. Close WADGUI dependencies of WADGUI are still listed as dependencies of WAD. a. If I reopen WADGUI now it works just file. b. If I close WADJDO or WADDS which are projects WADGUI is dependent on and that were added to WAD as dependencies by WADGUI, WAD will now complain thats its missing required project WADJDO or WADDS depending on which I close. 8. Close WAD 9. Reopen WAD The dependencies added by WADGUI are now gone from WAD. 10. Open WADGUI Back where we started with WADGUI not finding its dependencies. Note, when I say the dependencies of WADGUI are added to WAD I mean its listed in the project's "Plug-in Dependencies" folder. What shows up in the manifest editor is never changed. Are fragments really supposed to add their dependencies to the plugins they are fragmenting? Seems like an insecure idea. However, since they run in the plugins classloader they will be loading their classes into the plugins classloader so the classpath is actually being extended at runtime anyway. I think the bug is that when a fragment is opened or closed, the parent project needs its classpath reevaluated. Not just when the manifest is touched. That is if its proper for fragments do extend the classpath of plugins. As you suspected, it is NOT proper for the development classpath of a plug-in to have dependencies from its fragments. The reason why they are showing up is due to bug 109383. A plug-in can exist without fragments, and therefore its code must not depend on some dependency in a fragment for it to compile. Plug-ins must remain unaware of fragments. therefore, although it is technically correct that at runtime, the fragment and host will have the same classloader, etc., the tooling (PDE) should not be optimized to encourage/embed such fragment knowledge into the plug-in at development time. It would just encourage bad design. I will close this bug report as invalid. The real issue that caused the confusion is bug 109383 "As you suspected, it is NOT proper for the development classpath of a plug-in to have dependencies from its fragments." Right. Please tell Eclipse to stop doing that. The plug-in has no dependencies or knowledge of its fragments. Those "plug-in Dependencies" were not added by myself but added by eclipse after i touched the manifest. The difference between this bug and bug 109383 is, the fragment's classpath doesen't work until Eclipse performs this illegal act. In the other bug they are concerned about the illegal act itself, not the fact that fragments are not working until it is performed. As it stands if bug 109383 were fixed it seems that fragments would break. Plus this one was first :P Please re-read comment #5 and I will explain any questions you have about it. To be more clear, the main plugin 'WAD' has no dependencies on the fragments. The fragment WADGUI depends on WADJDO and WADDS. It imports those two plugins itself because the main plugin does not need nor use WADJDO or WADDS. When the fragment WADGUI is first opened its "Plug-in Dependencies" shows up empty! and it will not compile. Good catch. There is certainly a bug in the resolver here. I'm moving to Tom's bucket. Here is a simple test case: 1. Fresh workspace. 2. Create a new fragment project with the plugin (org.eclipse.core.filebuffers) as its host. 3. the fragment project will be created with the correct classpath. The classpath will contain the host and all its pre-reqs. All good. 4. Go to the dependencies page of the fragment and add 'org.apache.lucene'. Save. 5. The classpath of the fragment is now augmented with the lucene jars. All good. 6. Close the fragment project. 7. Reopen the fragment project. Observe how the classpath of the fragment is now screwed up. It only contains the lucene JARs. The fragment has become unresolved and has lost all connectivity to its host. There appears to be a bug in the incremental resolve of the state when we add a fragment that has its own Require-Bundle. The problem does not occur if the fragment has no direct dependencies, ie. if steps 4-5 above are skipped. Moving back to Wassim to fix in PDE. Wassim let me know if you have problems fixing this in PDE by re-resolving the host bundle. *** Bug 124932 has been marked as a duplicate of this bug. *** Can we get this one fixed for 3.2? It's quite a frustrating bug and if users aren't aware of the "workaround" (close and open the projects) then they won't be able to run their code because of the false compile errors. Fixed by forcibly refreshing the host's bundle description if a fragment that has its own constraints is added to the state. |