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"
m (Added API category tag) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | The | + | The [[Eclipse]] top-level 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. | * ALL Eclipse SDK plugins must list ALL of their packages in their MANIFEST.MF files. | ||
| Line 9: | Line 9: | ||
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. | 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 | + | 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 PDE API Tools, 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. | 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. | ||
[[Category:API]] | [[Category:API]] | ||
Revision as of 18:02, 2 February 2011
The Eclipse top-level 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 PDE API Tools, 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.