¿Por qué ha cambiado la API de Eclipse de forma incompatible entre 2.1 y 3.0?
Eclipse 3.0 es una evolución de Eclipse 2.1. Había algunas áreas en las que no ha sido posible evolucionar Eclipse al tiempo que se mantenía una compatibilidad perfecta en la placa. Las cuatro fuentes principales de incompatibilidades son:
La lista de incompatibilidades específicas.
¿Funcionará un conector de la versión 2.1 en 3.0?
Sí, excepto en algunos casos. Si un conector se basa sólo en las API de Eclipse 2.1, seguirá funcionando en la versión 3.0. Las poquísimas excepciones corresponden a lugares de la API en los que los cambios entre las versiones 2.1 y 3.0 no han podido realizarse de forma compatible; si un conector utiliza uno de ellos, no funcionará.
Mi conector 2.1 utiliza clases de paquetes internos. ¿Seguirá funcionando en Eclipse 3.0?
Si un conector se basa en clases internas o en comportamiento no especificado en la API de Eclipse 2.1, es imposible saber de antemano si el conector funcionará en la versión 3.0. Será necesario probarlo.
¿Cómo ejecutar el conector en Eclipse 3.0 sin modificarlo?
Instale el conector de la versión 2.1 en el subdirectorio eclipse/plugins/ de un producto basado en Eclipse 3.0 y reinicie Eclipse. Eclipse reconocerá que se trata de un conector 2.1 sin convertir (por la cabecera del archivo plugin.xml) y realizará automáticamente los ajustes para compensar los cambios realizados en las dependencias del conector de plataforma y los puntos de extensión de plataforma redenominados.
¿Deberá modificarse un conector de la versión 2.1 para que se compile correctamente en Eclipse 3.0?
Sí, en todos los casos. Existen ciertas diferencias entre Eclipse 2.1 y 3.0 que exigen cambios en todos los conectores migrados. Si tiene un conector escrito para 2.1 y desea recompilarlo, debe migrarlo a 3.0 para poder desarrollarlo en mayor grado para 3.0.
¿Cómo migrar el conector a Eclipse 3.0?
Una vez cargado (o importado) el proyecto de conector a un área de trabajo de Eclipse 3.0, utilice Herramientas de PDE > Migrar a 3.0 (menú de contexto del proyecto) para convertir el manifiesto del conector al formato 3.0 y ajustar automáticamente la lista de conectores y referencias de plataforma necesarias a los puntos de extensión de plataforma redenominados. En la mayoría de los casos, el código del conector debe compilare y ejecutarse satisfactoriamente después de esta operación. A continuación, debe revisarse el código del conector para asegurarse de que no depende de ninguna de las áreas de cambios incompatibles de la API.
¿Puede confiarse en que un conector emitirá errores o avisos de compilación si se basa en una API que ha cambiado de forma incompatible?
No. Existen algunas áreas de cambio incompatible que el compilador Java no indica.
¿Pueden ignorarse sin problemas los avisos del código derivados del uso de una API obsoleta?
Sí, a corto plazo. Siempre que es posible, las API obsoletas se marcan como tales en lugar de suprimirse directamente y siguen funcionando (aunque posiblemente sólo en condiciones limitadas). Por tanto, aunque generalmente no es urgente dejar de utilizar la API obsoleta, el hecho de que actualmente se considere así significa que ahora existe una mejor forma de realizar la tarea. Los conectores deben abandonar toda utilización de la API obsoleta lo antes posible.
Una vez migrado el conector a Eclipse 3.0, ¿se puede aún instalar y ejecutar el conector binario resultante en Eclipse 2.1?
No. Esto no está soportad y probablemente ni funcionará debido a los puntos de extensión redenominados.
¿Cuál es la finalidad de org.eclipse.core.runtime.compatibility?
En la versión 3.0, la adopción de un entorno de ejecución basado en OSGi ha convertido en obsoletas algunas de las API de entorno de ejecución del núcleo existentes. En la medida de lo posible, las API obsoletas de los paquetes org.eclipse.core.runtime.*, junto con la implementación subyacente, se han trasladado del conector org.eclipse.core.runtime al nuevo conector org.eclipse.core.runtime.compatibility. Por omisión, los conectores recién creados dependen de org.eclipse.core.runtime y se espera que sólo utilicen las API de entorno de ejecución no obsoletas. Por otra parte, los conectores existentes migrados desde 2.1 dependerán por omisión de org.eclipse.core.runtime.compatibility y pueden utilizar también las API antiguas (el conector org.eclipse.core.runtime.compatibility reexporta las API de org.eclipse.core.runtime). Aunque probablemente el conector org.eclipse.core.runtime.compatibility se incluirá en las configuraciones del IDE de Eclipse, huelga decir que no es probable que se incluya en los productos basados en configuraciones RCP.
¿Cuál es la finalidad de org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility es un fragmento de conector que suministra compatibilidad binaria mejorada para los conectores 2.1 ejecutados en un producto basado en Eclipse 3.0. En la versión 3.0, seis métodos con una dependencia explícita de IFile o IMarker se han transferido de la interfaz org.eclipse.ui.IWorkbenchPage a fin de separar netamente el entorno de trabajo del área de trabajo y los recursos. El fragmento org.eclipse.ui.workbench.compatibility organiza la readición de estos métodos a fin de que los conectores 2.1 existentes puedan ejecutarse sin modificaciones. Sin embargo, tenga en cuenta que los conectores migrados a 3.0 que hagan referencia a métodos transferidos recibirán errores de compilación que (sólo) podrán resolverse 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).