Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Export-Package"

(Add notice about migration to Github)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The eclipse project uses the following convention for the Export-Package manifest attribute:
+
{{Warning|This page has been migrated to https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/Export-Package.md}}
  
* ALL Eclipse SDK plugins must list ALL of their packages in their MANIFEST.MF files. 
+
The [[Eclipse]] top-level project uses the following convention for the Export-Package manifest attribute:
* 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.
+
* Newly added internal packages should not use x-internal exports unless there are very good reasons
 
+
* For existing packages the x-internal export can be removed with PMC approval
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.
+
* Using x-friends is OK and should always be preferred over x-internals. The use of x-friends is an indication of tightly coupled bundles because its use is for when one bundle needs "approved" access to the internals of another bundle.
 
+
* The 'Unexported package' Plug-in Manifest compiler option should be set to 'Warning'
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.
+
[[Category:API]]
 
+
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.
+
 
+
 
+
----
+
Back to [[API Central]]
+

Latest revision as of 08:02, 1 February 2024


The Eclipse top-level project uses the following convention for the Export-Package manifest attribute:

  • Newly added internal packages should not use x-internal exports unless there are very good reasons
  • For existing packages the x-internal export can be removed with PMC approval
  • Using x-friends is OK and should always be preferred over x-internals. The use of x-friends is an indication of tightly coupled bundles because its use is for when one bundle needs "approved" access to the internals of another bundle.
  • The 'Unexported package' Plug-in Manifest compiler option should be set to 'Warning'

Back to the top