¿Por qué la API de Eclipse cambia de forma incompatible entre 2.1 y 3.0?
Eclipse 3.0 es una evolución de Eclipse 2.1. Hay pocas áreas en que no hemos podido hacer evolucionar Eclipse mientras se mantenía una compatibilidad perfecta entre ambas versiones. Las cuatro fuentes principales de incompatibilidades son:
La lista de incompatibilidades específicas.
¿Un conector 2.1 funcionará en Eclipse 3.0?
Sí, salvo en algunos casos. Si un conector se basa sólo en las API de Eclipse 2.1, seguirá funcionando en 3.0. Las escasísimas excepciones son los lugares de la API donde los cambios entre la 2.1 y la 3.0 no se han podido realizar de manera compatible; si un conector utiliza uno de ellos, no funcionará.
Mi conector 2.1 utiliza clases en paquetes internos. ¿Seguirá funcionando en Eclipse 3.0?
Si un conector se basa en clases o funcionamiento internos no especificados en la API de Eclipse 2.1, es imposible afirmar con seguridad si el conector va a funcionar o no en 3.0. Tendrá que probarlo.
¿Cómo ejecuto mi conector en Eclipse 3.0 sin tocarlo?
Instale el conector 2.1 en el subdirectorio eclipse/plugins/ de un producto basado en Eclipse 3.0 y reinicie Eclipse. Eclipse reconocerá que el conector es un conector 2.1 no convertido (por la cabecera en plugin.xml) y automáticamente hace ajustes para compensar los cambios en las dependencias de conectores de plataforma y puntos de extensión de plataforma redenominados.
¿Es necesario cambiar los conectores 2.1 para que se compilen adecuadamente en Eclipse 3.0?
Sí, en todos los casos. Hay determinadas diferencias entre Eclipse 2.1 y 3.0 que requieren que se apliquen cambios a todos los conectores. Si tiene un conector escrito para 2.1 y desea volver a compilarlo, tiene que migrarse a 3.0 antes de que pueda seguir desarrollándose en 3.0.
¿Cómo migro mi conector a Eclipse 3.0?
Una vez que haya cargado (o importado) el proyecto de conector en un área de trabajo de Eclipse 3.0, utilice Herramientas PDE > Migrar a 3.0 (menú de contexto de proyecto) para convertir el manifiesto del conector al formato 3.0 y ajustar automáticamente la lista de conectores y referencias de plataforma a puntos de extensión de plataforma que se redenominaron. En la mayor parte de los casos, el código del conector debe compilarse y ejecutarse satisfactoriamente. A continuación, el código del conector debe revisarse para asegurarse de que no dependa de una de las áreas de cambio incompatible de API.
¿Puedo confiar en que un conector tendrá errores o avisos de compilación si se basa en una API que ha cambiado de manera incompatible?
No. Hay áreas de cambio incompatible que el compilador Java no marca con distintivos.
¿Puedo pasar por alto avisos en el código que procedan del uso de una API desechada?
Sí, a corto plazo. Siempre que es posible, las API obsoletas se marcan como desechadas en vez de ser suprimidas directamente y continúan funcionando (aunque posiblemente sólo bajo condiciones limitadas). Así pues, aunque generalmente no hay apremios para descartar la API desechada, el hecho de que ahora se considere obsoleta quiere decir que hay una manera mejor de hacer algo. Los conectores deben prescindir de todos los usos de una API desechada lo antes posible.
Una vez que migre mi conector a Eclipse 3.0, todavía puedo instalar y ejecutar el conector binario resultante en Eclipse 2.1?
No. No está soportado y probablemente no funcionaría debido a los puntos de extensión redenominados.
¿Cuál es el propósito de org.eclipse.core.runtime.compatibility?
El movimiento en 3.0 a un entorno de ejecución con base OSGi ha hecho obsoletas algunas API de entorno de ejecución de núcleo existentes. Cuando fue posible, las API obsoletas de los paquetes org.eclipse.core.runtime.*, junto con la implementación subyacente, se movieron desde el conector org.eclipse.core.runtime a un nuevo conector org.eclipse.core.runtime.compatibility. Por omisión, los conectores recién creados dependen de org.eclipse.core.runtime y se espera utilizar sólo las API de entorno de ejecución no desechadas. Por otro lado, los conectores existentes que se migran desde 2.1 dependerán por omisión de org.eclipse.core.runtime.compatibility y podrán utilizar también las API antiguas (el conector org.eclipse.core.runtime.compatibility vuelve a exportar las API de org.eclipse.core.runtime). Mientras que es probable que el conector org.eclipse.core.runtime.compatibility se incluya en las configuraciones IDE de Eclipse, es evidentemente improbable que se incluya en productos basados en configuraciones RCP.
¿Cuál es el propósito de org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility es un fragmento de conector que proporciona compatibilidad binaria aumentada para los conectores 2.1 que se ejecutan en un producto basado en Eclipse 3.0. En 3.0, seis métodos con una dependencia explícita de IFile o IMarker se movieron desde la interfaz org.eclipse.ui.IWorkbenchPage para separar claramente el entorno de trabajo del área de trabajo y los recursos. El fragmento org.eclipse.ui.workbench.compatibility organiza la adición de vuelta de estos métodos para que los conectores 2.1 existentes puedan ejecutarse sin modificaciones. No obstante, tenga en cuenta que los conectores que se migran a 3.0 que hacen referencia a los métodos movidos verán errores de compilación que (sólo) pueden solucionarse llamando a los métodos de sustitución ubicados ahora en org.eclipse.ui.ide.IDE.
Los métodos IWorkbenchPage en cuestión son: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) y openSystemEditor(IFile).