Bug 130598 - use of manifest.mf should be a release requirement
Summary: use of manifest.mf should be a release requirement
Status: RESOLVED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Process (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Eclipse Management Organization CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-06 13:31 EST by Jeff McAffer CLA
Modified: 2007-08-10 17:23 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff McAffer CLA 2006-03-06 13:31:06 EST
It just came to my attention that the DTP folks are using the old style plugin definition (i.e., using plugin.xml for their runtime information).  Do you think it reasonable to mandate that all projects releasing at eclipse.org use the new OSGi-style MANIFEST.MF markup?

I put this forward for the following reasons:
- better peformance since the runtime does not have to generate the manifests under the covers
- improved ability to manage APIs.  The correct and widespread use of x-internal and x-friends to define APIs enables PDE to highlight areas of API boundary crossing early (as the developer saves code) and promote API hygiene.
- improved integration.  By using the OSGi standard markup, components can opt into various tools and infrastructure (e.g., provisioning) designed to owrk with OSGi elements.
- It is "the" way plugins are defined since 3.1.
Comment 1 David Williams CLA 2006-03-06 16:26:42 EST
I would add my "vote" that I think it reasonable, and desirable. 

I did notice at last minute before our WTP M5 we had 3 or 4 plugins not converted (which I did convert for our M5) ... and it was partially due to to the mis-conception from some developers that using the manifest.mf form was also mean it had to be a jarred plugin. Which is not true. It is probably too much to ask making "jarred plugins" a requirement release ... though we hope to ... but in some cases will does require some code to be re-rewriten. 

BUT, it is very important (and easy) to do the manifest.mf files, so the "x-internal" mark-up can be used. (And, I'm sure, other reasons). 

Comment 2 Jeff McAffer CLA 2006-03-06 17:15:50 EST
David, but you didn't actually add your vote!

yes, jar'd plugins should be strongly recommended as the norm.  There are various performance benefits as well as again, being "the Eclipse way". Note that there should be lots of doc around from the 3.0 and 3.1 days on how to do the migration/conversion, as well as the trade-offs.

Comment 3 David Williams CLA 2007-06-28 13:00:22 EDT
Europa is better, but I see we forgot to make it a requirement? 

There's three plugins on Europa site without manifests ... I've opened bugs on STP and AspectJ. 

org.eclipse.aspectj_1.5.0.200706070619.jar 
org.eclipse.stp.doc_0.5.0.200705300907.jar 
org.eclipse.stp.sc.doc_0.5.0.200705300907.jar

Comment 4 David Williams CLA 2007-08-10 17:23:01 EDT
I'm closing this bug as "fixed" as I've added the requirement to the "must do" list for Ganymede. 
http://wiki.eclipse.org/Ganymede_Simultaneous_Release#Must_Do