Bugzilla – Full Text Bug Listing
| Summary: | [osgi] headers incorrectly cached when a bundle is installed from the update manager | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Boldt <nboldt> |
| Component: | Runtime | Assignee: | Pascal Rapicault <pascal> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dj.houghton, dsmall, Ed.Merks, jeffmcaffer, marcelop, pascal, rory.steele, sonia_dimitrov, steven.wasleski, wassim.melhem |
| Version: | 3.0 | ||
| Target Milestone: | 3.0.1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Nick Boldt
Additional details and screen shots can be seen here: http://emf.torolab.ibm.com/viewcvs/indextools.cgi/~checkout~/emf-home/docs/UsingUpdateManager/UsingUpdateManager.html Planned test scenarios (I only got as far as the first 4 since they all failed): http://emf.torolab.ibm.com/viewcvs/indextools.cgi/~checkout~/emf-home/docs/UsingUpdateManager/UM-test-scenarios.txt Screen shots of the problems encountered in the A4 scenario: http://emf.torolab.ibm.com/viewcvs/indextools.cgi/~checkout~/emf-home/docs/UsingUpdateManager/ScenarioA4.html Investigation started as result of this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=70129 and thus may be related, or at least another way of identifying the problem. I can't reproduce his stack trace, however, but I have encountered something similar in the past with trying to get an EMF Project to open in a "dirty" install of Eclipse. Are you running win2k on NTFS? If no, do you see the problem on a windows machine with NTFS? Can you attach the log file? Thanks. *** Bug 70129 has been marked as a duplicate of this bug. *** Just a couple of comments, slightly related to this bug (I am investigating it now): The eclipse About dialog should only show branding features, not all the features installed. A branding feature is a feature that defines an associated branding plugins, either explicitly with "plugin" attribute in its feature.xml or by contributing a plugin with the same id as the feature. Branding info is usually taken out of the about.ini file contained in the associated branding plugin. It looks like EMF is contributing 9 features as branding features. That's fine, but personally I think it is a bit too much. The more important issue is the branding attributes: providerName, etc. should be defined in the about.ini, even though this may seem redundant, as some of those values are also defined in feature.xml. This I think is a bug/limitation in the update code, as it should pick the provider name from about.ini first, and if not found, from the feature.xml. I have to retract the last comment: the provider name is picked up from the branding plugin.xml, not from about.ini. Mea culpa... Created attachment 13371 [details]
Eclipse Workspace .log file for Scenario A1
Eclipse Workspace .log file for Scenario A1
Created attachment 13372 [details]
Eclipse Workspace .log file for Scenario A2
Eclipse Workspace .log file for Scenario A2
Created attachment 13373 [details]
Eclipse Workspace .log file for Scenario A3
Eclipse Workspace .log file for Scenario A3
Created attachment 13374 [details]
Eclipse Workspace .log file for Scenario A4
Eclipse Workspace .log file for Scenario A4
Per question re: Win2K on NTFS, yes, I'm getting this behaviour on a lab-standard-installed T40. Log files for Scenarios A1-A4 attached. Thanks Nick, I am able to reproduce the problem as well. BTW, as I was following the steps to reproduce, I have encountered another problem, bug 70229. Do you see that behavior? re: bug 70229 Yes, definitely. Some thoughts on that issue posted on that bug's page. I think these items may be related. Are there any other UM sites for other Eclipse plugins encountering these problems? If so, then it's platform... if not, then it could be my site.xml content, per that other bug. Pascal, please take a look at this problem, it appears that there is some incorrect caching of bundle manifest headers. Here is the simplified summary of this bug: 1. use eclipse 3.0 to install EMF SDK 3.0 2. as these are new plugins, the user can just click "Apply Now" so he does not need to restart after install. 3. the user can see all the features and plugins in the About dialog, in particular the provider name is Eclipse.org 4. restart eclipse. At this point, the About dialog shows nothing for the provider name. The provider name is obtained by the update code by getting the Bundle and doing getHeaders(). It appears that the headers have been incorrectly cached. 5. to validate this, remove the configuration/org.eclipse.osgi and configuration/org.eclipse.core.runtime, but leave the org.eclipse.update untouched. 6. restart, things work fine, the provider of the new features/plugins is Eclipse.org 7. shutdown and restart again, the provider is blanc. To me, it looks like some odd behavior in manifest caching, and cannot see any unusual behavior in the update code. Please investigate a bit and see if you spot a problem in the framework. Thanks! *** Bug 71211 has been marked as a duplicate of this bug. *** Nothing new on this bug in the past month (aside from dupe report). Is anyone still looking at this problem? Thanks! I believe this bug is two fold. One is related to runtime (regarding the problematic display of the headers) and the other seems to be related to PDE (bugs #71823 and #72111). Moving to platform runtime for the problem related to the manifest since the others have already been fixed. CC'ing Wassim for confirmation. Correct. The fact that the plug-ins were missing in the runtime workbench was caused by bug 71823. Investigate for 3.0.1 Pascal, FYI: we had a similar bug fixed a week ago: see bug 71003 comment 3. The problem there would only appear for plug-ins that happen to have a incomplete MANIFEST.MF, for the second and successive times you run, but not for the first one. *** This bug has been marked as a duplicate of 71003 *** The following tests confirm that this bug is closed. Starting with bare Eclipse install, then used UM against the EMF Secondary Update Manager Site (http://emf.torolab.ibm.com/tools/emf/updates/, http://downloads.eclipse.org/tools/emf/updates/, etc.) to add the new plugins, to a new plugin Install Location (as listed under Help > Software Updates > Manage Configuration... > Product Configuration). Several restarts later, still working. Tests used the following Eclipse and EMF builds. PASSED: EMF SDK 2.0.1.M200408261626, Eclipse 3.0.1.M20040825 PASSED: EMF SDK 2.0.1.M200408261626, Eclipse 3.1.0.N20040831 Also, to get around the issue of using a Discovery URL as an Update URL, I've opened a new feature request against Platform / Update to ask that more than one Update URL be possible (or to provide for secondary/alternate Update URLs) to continue to provide this level of support. see bug 73004 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=73004) Finally, there's a newly-discovered problem (unearthed as a result of this bugfix) that shows that the label "EMF/SDO/XSD Secondary Update Site" when checking for updates to previously-installed EMF versions appears as "%secondaryUpdateSiteName" instead. I think this is a result of not having secondaryUpdateSiteName=EMF/SDO/XSD Secondary Update Site appear in all 11 feature.properties files within the EMF SDK (incl. XSD & SDO), and will be testing this hypothesis with our next build. looks like this is now working. bug 72709 closed too. |