Community
Participate
Working Groups
Build Identifier: I20110127-2034 when first starting eclipse 3.7M5, the default "Target Platform" pointing to a 3.6.x product installation is not being loaded. the dependencies displayed point instead to the 3.7M5 versions of the plug-ins. as per the "Steps to reproduce", i tried starting from scratch, but got the same results. i notice that when i "Reload" the target platform, it tells me things are out of sync. once the re-load is finished, inspection of dependencies reveals that they are now the appropriate ones from the desired default "Target Platform", and the workspace re-build completes appropriately without problems. but if i quit eclipse and then restart, i am back to square one; the workspace is automatically rebuilt (or if i turn that feature off, the next re-build causes the same problems), and the errors that occur in my workspace due to the wrong "Target Platform" being the base are re-displayed in "Problems", and have to "Reload" again … after which, everything is back to normal again. this happens repeatedly, no matter how many times i quit eclipse and reload the Target Platform after restart. Reproducible: Always Steps to Reproduce: using "Plug-in Development" perspective the first 8 steps need only performed once: 1. requires a built eclipse product with access to source based upon eclipse 3.6 2. in eclipse 3.7M5, go to "Windows>Preferences", then filter "Target Platform" 3. hit "Add…", then "Next…" (start with an empty target definition) 4. on the "Locations" tab (which should come up automatically), hit "Add…" 5. hit "Browse…" and find the eclipse product build from step 1. 6. give it a name (or recognize the name as "New Platform" and use that) 7. hit "Finish" 8. hit "OK" the following steps can be repeated: 9. examine one of the source plug-ins that depends upon product plug-ins (e.g. org.eclipse.cdt.debug.edc has numerous dependencies on org.eclipse plug-ins such as org.eclipse.osgi_3.6.1.R36x_v20100806.jar) notice that the version should be from the "Target Platform" specified. if there is any question, examine the .jar file name using windows explorer by navigating to the product location and looking in the plugins folder 10. restart (i.e. quit eclipse, then start and choose the same workspace) 11. re-examine step 9. PASS: if the dependencies shown by inspection in step 9 are the same FAIL: if the dependencies shown by inspection in step 9 end up referring to the versions of the plug-ins found in the eclipse 3.7M5 install additional optional steps: 12. go to "Windows>Preferences" and filter "Target Platform" 13. hit Reload 14. re-examine as in steps 9 & 11 . after FAIL in step 11, this Reload shows that the plug-ins from the desired Target Platform are referenced steps 9 through 14 can be repeated ad infinitum for me and produce the same results.
So you have a target definition that points to a product. After each restart, the target definition still points to the product location but contains no plug-ins (or incorrect plug-ins?). Does you target definition use an 'installation' or 'directory' location? (This would be chosen between steps 4 and 5). The fact that reload works, suggests that something is not being stored correctly in the state (on restart, we do not resolve the target platform, we load the bundles from the saved state). You can view the current contents of the state through the Target Platform State View. I wasn't able to reproduce, if I have a target definition that points to a limited set of plug-ins, restarting did not affect the contents of my target platform. Is there something unique about the product your target points to? Does it use linked folders to add plug-ins? Was it started or modified between when the target definition was created and when you restarted?
Created attachment 189759 [details] Target Platform State view of org.eclipse.osgi before Reload (In reply to comment #1) > So you have a target definition that points to a product. After each restart, > the target definition still points to the product location but contains no > plug-ins (or incorrect plug-ins?). immediately after start, prior to "Reload" the "Target Platform" pref page "Content" tab, sorted by "File Path" shows plugins where they are supposed to be. however, the "Target Platform State" view shows at this pointn that all org.eclipse... plugins coming from the 3.7M5 plugins folder. for example, for osgi: "Target Platform" pref page: org.eclipse.osgi (3.6.1.R36x_v20100806) "Target Platform State" view: org.eclipse.osgi_3.7.0v20110124-0830 after "Reload" and then hitting OK through the dialogs that tell me things will be reloaded, the Target Platform State view changes to show the 3.6 plugins. > Does you target definition use an 'installation' or 'directory' location? > (This would be chosen between steps 4 and 5). both. (i forgot which i had done; the icon in my original target definition indicates i did "installation" the first time. but i tried both, and it failed the same way in both cases.) > The fact that reload works, suggests that something is not being stored > correctly in the state (on restart, we do not resolve the target platform, we > load the bundles from the saved state). You can view the current contents of > the state through the Target Platform State View. this is helpful, and i would modify the "Steps to reproduce" in the Description field to reflect this in steps 9, 11, and 14. (in the end, it amounts to the same thing, i guess.) > I wasn't able to reproduce, if I have a target definition that points to a > limited set of plug-ins, restarting did not affect the contents of my target > platform. Is there something unique about the product your target points to? > Does it use linked folders to add plug-ins? Was it started or modified between > when the target definition was created and when you restarted? the product that is being pointed to isn't being modified between the time i create the target definition and the time i restart. it does not use linked folders to add plug-ins. it may be unique. i'm attaching a couple of screenshots of the Target Platform View w.r.t. to the org.eclipse.osgi plugins. the same thing seems to happen with org.apache.commons, org.apache.lucene, and some basic org.eclipse plugins such as org.eclipse.core.filesystem, et al.
Created attachment 189760 [details] Target Platform State view of org.eclipse.osgi after Reload
additional info: the target platform definition i was creating pulled in two plugins from the eclipse install that are not in the targeted product: pde & jdt for the purpose of running JUnit tests. i re-installed (well, unpacked from my backup .zip) 3.6.1, and pulled in those pde & jdt plugins instead. i am guessing that because the 3.7M5 pde & jdt plugins were already loaded and already pulled had some sort of dependency pointers on osgi and other core eclipse plugins from the ${eclipse_home} site at startup, that these were what ended up in the Target Platform state prior to hitting the "Reload" button … but after "Reload", they were able to get their dependencies met completely from the designated Target Platform definition as i had intended. this workaround (pointing to the old 3.6.1 versions of pde & jdt for running junit tests) is sufficient for my purposes. (and i'll understand if you call this user error, though i think it should be valid to pull in plugins and have their dependencies fulfilled as i had originally intended in my target definition without having to reload.)
There could still be some bugs here relating to duplicate bundle management. The target definition will remove duplicate plug-ins, but which plug-in is chosen is based on the order in which the locations resolve (unless we have some code that checks for the highest version). On restart, the state will load it's plug-ins from a saved list of url locations (not the target). However, since the urls shouldn't change between the restart, the state should have the same contents after the restart. The fact that the state changes and reload says your target is out of synch means that the content is not getting saved correctly. I don't have time to debug through this right now. On restart we load bundles in ExternalModelManager.getPluginPaths().
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.
This bug was marked as stalebug a while ago. Marking as wontfix. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
