The eclipse project uses the following convention for the Export-Package manifest attribute:

+

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 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 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]]

Latest revision as of 17: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.