Preguntas más frecuentes (FAQ) acerca de la migración de plug-ins a Eclipse 3.0

¿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 plug-in 2.1 funcionará en Eclipse 3.0?

Sí, salvo en algunos casos. Si un plug-in 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 plug-in utiliza uno de ellos, no funcionará.

Mi plug-in 2.1 utiliza clases en paquetes internos. ¿Seguirá funcionando en Eclipse 3.0?

Si un plug-in se basa en clases o funcionamiento internos no especificados en la API de Eclipse 2.1, es imposible afirmar con seguridad si el plug-in va a funcionar o no en 3.0. Tendrá que probarlo.

¿Cómo ejecuto mi plug-in en Eclipse 3.0 sin tocarlo?

Instale el plug-in 2.1 en el subdirectorio eclipse/plugins/ de un producto basado en Eclipse 3.0 y reinicie Eclipse. Eclipse reconocerá que el plug-in es un plug-in 2.1 no convertido (por la cabecera en plugin.xml) y automáticamente hace ajustes para compensar los cambios en las dependencias de plug-ins de plataforma y puntos de extensión de plataforma redenominados.

¿Es necesario cambiar los plug-ins 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 plug-ins. Si tiene un plug-in 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 plug-in a Eclipse 3.0?

Una vez que haya cargado (o importado) el proyecto de plug-in en un espacio de trabajo de Eclipse 3.0, utilice Herramientas PDE > Migrar a 3.0 (menú de contexto de proyecto) para convertir el manifiesto del plug-in al formato 3.0 y ajustar automáticamente la lista de plug-ins 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 plug-in debe compilarse y ejecutarse satisfactoriamente. A continuación, el código del plug-in debe revisarse para asegurarse de que no dependa de una de las áreas de cambio incompatible de API.

¿Puedo confiar en que un plug-in 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 plug-ins deben prescindir de todos los usos de una API desechada lo antes posible.

Una vez que migre mi plug-in a Eclipse 3.0, todavía puedo instalar y ejecutar el plug-in 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 plug-in org.eclipse.core.runtime a un nuevo plug-in org.eclipse.core.runtime.compatibility. Por omisión, los plug-ins 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 plug-ins 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 plug-in org.eclipse.core.runtime.compatibility vuelve a exportar las API de org.eclipse.core.runtime). Mientras que es probable que el plug-in 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 plug-in que proporciona compatibilidad binaria aumentada para los plug-ins 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 espacio 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 plug-ins 2.1 existentes puedan ejecutarse sin modificaciones. No obstante, tenga en cuenta que los plug-ins 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).