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 "FAQ How do I prevent my plug-in from being broken when I update Eclipse?"
m |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Eclipse makes a careful distinction between published APIs and internal implementation details. The APIs are designed to reduce coupling between plug-ins to a small, stable interface. This insulates clients of the interface from being affected by implementation changes, and it allows the plug-in that publishes the interface to continue to innovate and grow without breaking existing clients. If your plug-in uses only published API and carefully follows the API contracts defined in the API javadoc, your plug-in should continue to work after migrating to a new Eclipse release. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Eclipse makes a careful distinction between published APIs and | + | |
| − | internal implementation details. The APIs are designed to | + | |
| − | reduce coupling between plug-ins to a small, stable interface. This insulates clients | + | |
| − | of the interface from being affected by implementation changes, and it | + | |
| − | allows the plug-in that publishes the interface to continue to innovate and | + | |
| − | grow without breaking existing clients. If your plug-in uses only published | + | |
| − | API and carefully follows the API contracts defined in the API javadoc, | + | |
| − | your plug-in should continue to work after migrating to a new Eclipse release. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | In the Eclipse Platform, the API of a plug-in includes all public classes and interfaces that do not have the word <i>internal</i> in their package names and all public and protected methods in those classes and interfaces. The API also includes all extension points that are not explicitly described as for internal use only in their documentation; there is only a small handful of such internal extension points. | ||
== See Also: == | == See Also: == | ||
| + | *[http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html Eclipse online article "How to Use the Eclipse API"] | ||
| + | *[http://www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/02_des_Rivieres.pdf EclipseCon 2004 technical track presentation, "Eclipse APIs: Lines in the Sand"] | ||
| − | + | {{Template:FAQ_Tagline}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 20:11, 29 May 2006
Eclipse makes a careful distinction between published APIs and internal implementation details. The APIs are designed to reduce coupling between plug-ins to a small, stable interface. This insulates clients of the interface from being affected by implementation changes, and it allows the plug-in that publishes the interface to continue to innovate and grow without breaking existing clients. If your plug-in uses only published API and carefully follows the API contracts defined in the API javadoc, your plug-in should continue to work after migrating to a new Eclipse release.
In the Eclipse Platform, the API of a plug-in includes all public classes and interfaces that do not have the word internal in their package names and all public and protected methods in those classes and interfaces. The API also includes all extension points that are not explicitly described as for internal use only in their documentation; there is only a small handful of such internal extension points.
See Also:
- Eclipse online article "How to Use the Eclipse API"
- EclipseCon 2004 technical track presentation, "Eclipse APIs: Lines in the Sand"
This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.