| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html lang="en"> |
| <head> |
| <meta name="copyright" content="Copyright (c) IBM Corporation and others 2009. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css"> |
| <title>Eclipse 3.7 Plug-in Migration Guide</title> |
| </head> |
| |
| <body> |
| |
| <h1>Eclipse 3.7 Plug-in Migration Guide</h1> |
| <p>This guide covers migrating Eclipse 3.6 plug-ins to Eclipse 3.7.</p> |
| <p>One of the goals of Eclipse 3.7 was to move Eclipse forward while remaining compatible |
| with previous versions to the greatest extent possible. That is, plug-ins written |
| against the Eclipse 3.6 APIs should continue to work in 3.7 in spite of any API changes.</p> |
| <p>The key kinds of compatibility are API contract compatibility and binary compatibility. |
| API contract compatibility means that valid use of 3.6 APIs remains valid for |
| 3.7, so there is no need to revisit working code. Binary compatibility means |
| that the API method signatures, etc. did not change in ways that would cause |
| existing compiled ("binary") code to no longer link and run with the |
| new 3.7 libraries.</p> |
| <p>While every effort was made to avoid breakage, there are a few areas of incompatibility or new |
| APIs that should be adopted by clients. |
| This document describes those areas and provides instructions for migrating 3.6 plug-ins to |
| 3.7.</p> |
| <ul> |
| <li><a href="3.7/faq.html">Eclipse 3.7 Plug-in Migration FAQ</a></li> |
| <li><a href="3.7/incompatibilities.html">Incompatibilities between Eclipse 3.6 and 3.7</a></li> |
| <li><a href="3.7/recommended.html">Adopting 3.7 mechanisms and API</a></li> |
| </ul> |
| |
| </body> |
| </html> |