Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 71823 - empty manifest files included in update site downloads confuse PDE
Summary: empty manifest files included in update site downloads confuse PDE
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 critical (vote)
Target Milestone: 3.0.1   Edit
Assignee: PDE-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 70885 71716 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-08-11 15:42 EDT by Pratik Shah CLA
Modified: 2004-08-30 10:43 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pratik Shah CLA 2004-08-11 15:42:40 EDT
The jars on the Eclipse Update site (including EMF) have a META-INF folder 
with a manifest.mf file.  These files have just one line: Manifest-version: 
1.0.  The plug-ins are installed fine and show up in the list of plug-ins 
accessed via the About Eclipse dialog.  However, they don't show up in the 
list of PDE Target Platform Plug-ins or the list in Import External Plug-ins 
and Fragments wizard.

For us (GEF), this is also creating the problem that none of our externalized 
Strings in the plugin.properties file are being loaded.  However, I am not 
seeing this problem with other plug-ins from the Update site.  We'll look into 
this a bit more (it might be our loading mechanism).
Comment 1 Pratik Shah CLA 2004-08-11 15:48:20 EDT
Re-routing to PDE.

I'm not sure if the correct thing here is for the update site to not have 
those manifest.mf files, or for PDE to be able to recognize plug-ins with 
those manifest files.

Copying Sonia since she might know something about this.
Comment 2 Sonia Dimitrov CLA 2004-08-11 16:02:41 EDT
Are these files really bogus?
Comment 3 Pratik Shah CLA 2004-08-11 16:07:51 EDT
The problem with the Strings not being loaded properly seems to be valid.  
I've opened a separate bug report to track that: Bug# 71825
Comment 4 Wassim Melhem CLA 2004-08-12 00:28:23 EDT
When reading plug-ins from the target platform:
if the plug-in has a META-INF/manifest.mf file, we read it and if it does not 
contain a BUNDLE-SYMBOLICNAME header, we reject the plugin and go on to the 
next. (bug 62801)
In this case, these plugins contain an almost-empty manifest file and they are 
thus discarded.

Jeff, what does the runtime do in this case?  I presume it is more lenient in 
that if the manifest.mf is missing an id, it just reads the plugin.xml?
Comment 5 Wassim Melhem CLA 2004-08-12 00:31:51 EDT
*** Bug 71716 has been marked as a duplicate of this bug. ***
Comment 6 Jeff McAffer CLA 2004-08-12 10:36:37 EDT
the runtime looks for a plugin.xml and generates a manfiest which is integrated 
into the existing manifest and put in the cache area.

I would have thought that the state population code you have already did this 
but perhaps I am mistaken.
Comment 7 Wassim Melhem CLA 2004-08-17 01:10:04 EDT
3.0.1 candidate.

Fixed by making the reading of the registry less stringent.
If a plugin contains a bogus manifest, we do not dismiss it right away.
We check if it has a plugin.xml, we convert, and we then accept/reject based 
on the manifest resulting from the conversion.
Comment 8 Wassim Melhem CLA 2004-08-17 01:11:01 EDT
*** Bug 70885 has been marked as a duplicate of this bug. ***
Comment 9 Cherie Wong CLA 2004-08-30 10:43:09 EDT
Verified on M20040825.