Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Export-Package"
| Line 10: | Line 10: | ||
This approach is NOT at odds with, and is fundamentally separate from, our ongoing work to get control over the API and help developers stay on "the right path". That effort is supported by the addition of the component.xml files, the use of "x-internal" and "x-friends" annotations on export entries and the PDE/JDT work to more accurately model the runtime classpath at development time. | This approach is NOT at odds with, and is fundamentally separate from, our ongoing work to get control over the API and help developers stay on "the right path". That effort is supported by the addition of the component.xml files, the use of "x-internal" and "x-friends" annotations on export entries and the PDE/JDT work to more accurately model the runtime classpath at development time. | ||
| + | |||
| + | The PDE Tools > Organize Manifest operation will do the work for you, all you have to do is invoke the operation from time to time. | ||
Revision as of 15:46, 10 July 2006
The eclipse project uses the following convention for the Export-Package manifest attribute:
- ALL Eclipse SDK plugins must list ALL of their packages in their MANIFEST.MF files.
- API or not. If you have a package on your plugin's classpath, it must be listed.
- New? List it! Old? List it! Borrowed from a friend? List it!
Exceptions to this model should be taken up with the PMC.
Notice that this puts us in exactly the same situation as we have always been in. Everyone has the ability to see everything. The community's desire/need for the freedom to access non-API is overwhelming. In fact, this forms a critical part of the Eclipse ecosystem by allowing experimentation and investigation.
This approach is NOT at odds with, and is fundamentally separate from, our ongoing work to get control over the API and help developers stay on "the right path". That effort is supported by the addition of the component.xml files, the use of "x-internal" and "x-friends" annotations on export entries and the PDE/JDT work to more accurately model the runtime classpath at development time.
The PDE Tools > Organize Manifest operation will do the work for you, all you have to do is invoke the operation from time to time.