Bugzilla – Full Text Bug Listing
| Summary: | workspace didn't compile after restart - always have to reload Target Platform | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | ekkehard gentz <ekke> | ||||||||||||||
| Component: | UI | Assignee: | Darin Wright <darin.eclipse> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | P2 | CC: | aleksander.bandelj, aniefer, curtis.windatt.public, darin.eclipse, irbull, kresten+eclipse, ralf, tjwatson | ||||||||||||||
| Version: | 3.6 | Flags: | aniefer:
review+
|
||||||||||||||
| Target Milestone: | 3.6 RC1 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
ekkehard gentz
Created attachment 165417 [details]
thats the target platform
Curtis, I've seen this too. (In reply to comment #2) > Curtis, I've seen this too. always good to know that I'm not alone ;-) ekke I'm sure there is an open bug for this. I get the famous can't find org.eclipse. in my import statements. Usually a reload of the target or restart of eclipse fixes it, but it's not something that happens regularly enough to pin-point. I guess this is different in that you *always* get this error. (In reply to comment #4) > .... Usually a reload of the target or > restart of eclipse fixes it, but it's not something that happens regularly > enough to pin-point. I guess this is different in that you *always* get this > error. this was also my experience the last years: from time to time I had to reload the TP. but at the moment its needed after each restart I don't see anything special with my target platform - some update sites and one plugin from an unspecified update site. normaly my target platforms start with an empty target platform - in this case the target platform starts with the running IDE. (It's the redview developer target platform where we then launch the IDE as Eclipse Application together with bundles from target platform and workspace.) from my runtime projects with target platform I never had the case that I have to reload after each restart. don't know if there's a conjunction. ekke This only happens in some workspaces, but consistently. Even worse, in some of these workspaces even target platform reload doesn't work. Bug 276136 contains my patch for such hopeless situations, still needed in latest milestone. Anyway, my guess is a race condition during initialization, as above. This seems to be related to using a software site in the target. This morning I had to completely remove my targets and create a new one to get things working. My new target definition did not have a software site and restarting worked fine. I just added a site to the target (Eclipse Platform Launchers + Eclipse RCP from the IBuilds), and restarted and now I have the compile errors and org.eclipse.* not resolved. Clicking reload on the target gives a "The active target platform is out of synch with the filesystem" message. (In reply to comment #5) > I don't see anything special with my target platform - some update sites and > one plugin from an unspecified update site. Note that the contents of your target platform is probably not affecting your problem. When you set/reload a target platform, all of the information is stored in Eclipse preferences. On startup, we never look at the target platform, we just look at what is in the preferences. There must be a bug somewhere in the code that initializes the plug-in model manager on startup. One thing that you can check is the content of <workspace_loc>/.metadata/.plugins/org.eclipse.core.runtime/.settingsorg.eclipse.pde.core.prefs Specifically the values for platform_path, additional_locations, pooled_bundles and checkedPlugins. I should have been more clear, the contents of your target platform could change this bug (having an update site location means we need to store different values in pooled_bundles). But the bug is not a problem with the target platform code. Aleksander, if reloading the TP doesn't fix the issue, you are likely dealing with a different bug. (In reply to comment #7) > This seems to be related to using a software site in the target. > > This morning I had to completely remove my targets and create a new one to get > things working. My new target definition did not have a software site and > restarting worked fine. I just added a site to the target (Eclipse Platform > Launchers + Eclipse RCP from the IBuilds), and restarted and now I have the > compile errors and org.eclipse.* not resolved. > > Clicking reload on the target gives a "The active target platform is out of > synch with the filesystem" message. Andrew, this is exactly my situation. good to hear that you can reproduce this. from chris aniszczyk's blog I know that there will be an export - target platform to directory option from PDE in M7. so this could be a workaround from M7 on: * resolve TP * export to directory * switch to other TP definition loading all from directory * only for updates switch back to origin TP, then export again of course much better would be a fix ;-) ekke If you experience the problem, BEFORE resetting the target platform, can you copy and attach your prefs file: <workspace_loc>/.metadata/.plugins/org.eclipse.core.runtime/.settingsorg.eclipse.pde.core.prefs Created attachment 165484 [details]
my pde.core.prefs AFTER restart WITH error BEFORE reload TP
Your pooled_bundles entry looks correct assuming the versions match with the plug-ins in the bundle pool location: pooled_bundles=org.apache.commons.logging,1.1.1.v200904062255,org.eclipse.emf.ecore.change.edit.source,2.5.0.v201003151457,org.eclipse.emf.workspace.ui.source,1.3.0.v200901271819... The additional locations lists the bundle pool 5 time in a row, I assume because you have multiple remote repo locations in your target. This sounds like it would be straightforward to debug if I could reproduce consistently. If you are able to debug, take a look at what happens in ExternalModelManager.initializeModels(). This clearly needs some more investigation. I'll mark for M7, but time is running short :) (In reply to comment #13) > Your pooled_bundles entry looks correct assuming the versions match with the > plug-ins in the bundle pool location: > pooled_bundles=org.apache.commons.logging,1.1.1.v200904062255,org.eclipse.emf.ecore.change.edit.source,2.5.0.v201003151457,org.eclipse.emf.workspace.ui.source,1.3.0.v200901271819... > they do > The additional locations lists the bundle pool 5 time in a row, I assume > because you have multiple remote repo locations in your target. > yes > This sounds like it would be straightforward to debug if I could reproduce > consistently. If you are able to debug, take a look at what happens in > ExternalModelManager.initializeModels(). > I'll try... but the next 2 days I have to spend some time for customer project and also to finally test the fixed bug with unwanted RAP in IDE and restructure my update sites. > This clearly needs some more investigation. I'll mark for M7, but time is > running short :) I'll do my best to help, because a solution would help me, too ;-) ekke Curtis, you should be able to reproduce this by installing org.eclipse.rcp into your target from the IBuild site. The version should match the same version of the eclipse you are running. I'm not sure a p2 site is required, it may be sufficent to use another directory that contains the same bundles that are in the eclipse.home.
I did this with the "Include all environments" option checked (to simulate the deltapack).
In the prefs, "pooled_bundles" lists only those bundles that are not part of the base ${eclipse.home} install. In ExternalModelManager#initializeModels, first all model are enabled with VALUE_SAVED_ALL. Then the bundles that are part of the rcp feature from the site, but are also in the base ${eclipse.home} are disabled since they aren't in the pooled_bundles list.
Consider a bundle (org.eclipse.osgi) that exists in both the eclipse.home, and the bundle_pool.
- PluginModelManager#initializeTable(), fExternalManager#getPluginPaths() returns a list that includes both locations.
- PDEState#readTargetState, the state cache does not exist (perhaps because the timestamp includes duplicate bundles that won't make it into the final state?)
- urls are added to the state, which now contains duplicates
-PDEState#removeDuplicates, duplicates are removed. Here, the bundle from eclipse.home is removed, leaving the one from the bundle_pool.
-ExternalModelManager#initializeModels the bundle_pool bundle is disabled.
What should probably happen is that when removing duplicates, we keep the one that is enabled in the preferences, how to figure this out, I'm not quite sure. (Note that you can't rely on the order returned from getBundles since it is coming out of a hash set.
Also, if the timestamped cache matched up properly, then we probably wouldn't need the recompile at all(?) I hope I am not point out a red herring but this may be related to bug277185 (In reply to comment #17) > I hope I am not point out a red herring but this may be related to bug277185 Maybe race condition, could be similar to my favourite bug 276136 ? :) perhaps bug 310756 is related ? I'm getting InvalidRegistryObjectException while resetting the TP after restart. even in a fresh eclipse installation with fresh workspace using I20100426-0852 the exception doesn't happen always after each restart, but since 1 or 2 I-Builds from time to time ekke I can reproduce using Andrew's steps from comment#15 Created attachment 167531 [details]
patch
This patch stores bundles originating from the bundle pool with URLs, such that the state can be restored properly without adding all bundles from the pool and then disabling.
The problem: When the target is resolved initially, duplicates are removed (usually removed from the bundle pool, for example if o.e.osgi is in both the base and the pool). Then, we store a list of "used bundles (names & versions)" from the bundle pool. On restore, duplicates are removed (from the base instead of the pool), and bundles in the pool are disabled if they were not originally used... meaning both versions of a bundle can be removed from the state.
Additionally, the persisted target state was never being re-used on startup since the bundle URLs timestamp never matches (since the stored timestamp only included bundles used, and the computed timestamp includes all bundles in the pool). This patch also addresses this issue.
Caveat: basically, I'm using a new preference to store bundle URLs and no longer using the 3.5 preference that stored bundle names/versions. When re-starting a 3.5 workspace use of the bundle pool is detected and the target is automatically re-loaded. This extra hit should only happen once (as the old preference is then null'd out). Please review, Curtis. Created attachment 167540 [details]
updated patch
Updated to persist bundle file names relative to the bundle pool, in order to support a transportable workspace location.
I took the attached patch and applied it in my workspace, then exported org.eclipse.pde.core into the host. After the restart the target did get reloaded and the workspace recompiled ok. A second restart was good, the target did not get reloaded and there was no recompile, everything seemed happy. The only thing I notice is if after a restart, I manually got to the Target Platform Preferences and hit reload, then I do still get the "The active target platform is out of synch with the file system" message. Created attachment 167745 [details]
fixed patch
On restart, pooled bundles were incorrectly resolved relative to the bundle pool instead of the *plugins* directory in the bundle pool.
Andrew, please test the latest patch. The scenario is now working from me when installed into my host. (Reloading in the target workspace is always 'out of synch' since target weaving is not taken into account by the synch test). This is working well for me. When exporting into host, I must restart to pick up the new pde.core bundle. After this first restart, my target was still out of date. This may be expected as it would have been old code doing any persisting before the restart. After a second restart things are working fine. All subsequent restarts are good, I also edited my target to update the rcp & launcher features from the p2 repo and restarts after that were fine too. ...sounds great, what you've done to fix this :) thx to all let me know if there's an I-Build I can use to test with my scenarios ekke Hmm, doesn't work for me. I've patched org.eclipse.pde.core, installed in 3.6M7 and ...
java.lang.OutOfMemoryError: Java heap space
at java.util.HashMap.addEntry(HashMap.java:753)
at java.util.HashMap.put(HashMap.java:385)
at org.eclipse.osgi.internal.resolver.StateReader.readMap(StateReader.java:427)
at org.eclipse.osgi.internal.resolver.StateReader.readExportPackageDesc(StateReader.java:382)
at org.eclipse.osgi.internal.resolver.StateReader.readBundleDescriptionLazyData(StateReader.java:265)
at org.eclipse.osgi.internal.resolver.StateReader.readState(StateReader.java:132)
at org.eclipse.osgi.internal.resolver.StateReader.loadState(StateReader.java:613)
at org.eclipse.osgi.internal.resolver.StateObjectFactoryImpl.internalReadState(StateObjectFactoryImpl.java:387)
at org.eclipse.osgi.internal.resolver.StateObjectFactoryImpl.readState(StateObjectFactoryImpl.java:357)
at org.eclipse.pde.internal.core.PDEState.readStateCache(PDEState.java:247)
at org.eclipse.pde.internal.core.PDEState.readTargetState(PDEState.java:121)
at org.eclipse.pde.internal.core.PDEState.<init>(PDEState.java:100)
at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:480)
at org.eclipse.pde.internal.core.PluginModelManager.getEntryTable(PluginModelManager.java:460)
at org.eclipse.pde.internal.core.PluginModelManager.findEntry(PluginModelManager.java:831)
at org.eclipse.pde.internal.core.PluginModelManager.findModel(PluginModelManager.java:855)
at org.eclipse.pde.core.plugin.PluginRegistry.findModel(PluginRegistry.java:92)
at org.eclipse.pde.internal.core.TargetPlatformHelper.getTargetVersionString(TargetPlatformHelper.java:310)
at org.eclipse.pde.internal.core.TargetPlatformHelper.getTargetVersion(TargetPlatformHelper.java:363)
at org.eclipse.pde.internal.core.TargetPlatformHelper.getSchemaVersionForTargetVersion(TargetPlatformHelper.java:376)
at org.eclipse.pde.internal.core.TargetPlatformHelper.getSchemaVersion(TargetPlatformHelper.java:421)
at org.eclipse.pde.internal.core.plugin.PluginHandler.processingInstruction(PluginHandler.java:110)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.processingInstruction(AbstractSAXParser.java:711)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.processingInstruction(XMLDTDValidator.java:1018)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:475)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
(In reply to comment #30) i unapplied the patch and obviously this is caused by something else that changed in HEAD, please disregard. (In reply to comment #30) Nothing to do with HEAD either, reinstalling eclipse from scratch fixed that (grumble) [1]. Anyway, patch seems to work ok with v20100429, should work with HEAD as well. [1] automated that long time ago, with extension locations and shell scripts. Bug 305642 :) Chaning reviewer to Andrew, since Curtis is out of the office. If I understand things correctly, the change is that originally we were adding the whole bundle pool to the state and then disabling the ones that are not in the target. The patch is to only add the urls that were in the target in the first place instead of the whole pool. I like this change because if the user has upgraded the site in his target a few times, then we have multiple versions of everything in the pool. And it seems cleaner (and less work) to just not add them in the first place. One small thing I see is on the use of ',' to tokenize the list of file names since it is a valid character in linux filenames. However, I don't believe this should happen since we are looking at our own bundle pool, which I expect is just a SimpleArtifactRepository with default mapping rules. Presuming we only store features and osgi bundles, then we should never have any files with ',' in their name. PDE uses commas for similar purposes elsewhere. For now, I think this is reasonably safe. Applied/Fixed. verified: did some tests using RC1 all works well now thx for fixing this important issue ekke |