Cambios necesarios al adoptar los mecanismos y las API de la versión 3.2

Esta sección describe los cambios que deben realizarse si intenta cambiar el plug-in 3.1 para adoptar los mecanismos y las API de 3.2.

  1. Configuraciones de lanzamiento
  2. Modalidades de lanzamiento
  3. Componentes internacionales de Unicode para Java (ICU4J)
  4. División del entorno de ejecución

Configuraciones de lanzamiento

Correlación de recursos de configuración de lanzamiento

Eclipse 3.2 proporciona una infraestructura nueva para asociar configuraciones de lanzamiento a recursos. Esta correlación permite a la plataforma realizar el filtrado basado en recursos sobre configuraciones de lanzamiento y permite a la plataforma suprimir opcionalmente configuraciones de lanzamiento cuando se suprime un proyecto asociado. El diálogo de lanzamiento se ha mejorado de forma que soporte un conjunto de filtros para poder ocultar las configuraciones asociadas a los proyectos cerrados y suprimidos. Además, el diálogo de lanzamiento soporta el filtrado basado en los conjuntos de trabajo seleccionados en la ventana activa del entorno de trabajo que también puede seleccionarse en el diálogo de lanzamiento.

Es responsabilidad de un cliente gestionar la correlación de recursos para las configuraciones de lanzamiento. Se ha añadido la API a ILaunchConfigurationWorkingCopy para establecer los recursos asociados a una configuración y se ha añadido una API a ILaunchConfiguration para obtener los recursos asociados a una configuración. Por ejemplo, las pestañas de lanzamiento, los accesos directos de lanzamiento y los participantes en la refactorización deben tenerse en cuenta al migrar. El código que crea o modifica las configuraciones de lanzamiento también debe actualizar correlaciones de recursos.

Soporte de migración de configuración de lanzamiento

Eclipse 3.2 proporciona una infraestructura nueva para que la migración de configuraciones de lanzamiento sea compatible con las herramientas nuevas. Por ejemplo, en Eclipse 3.2, se ha añadido soporte para aplicar un filtro basado en recursos sobre las configuraciones de lanzamiento. Es necesario actualizar las configuraciones de lanzamiento para proporcionar correlaciones de recursos que aprovechen esta característica nueva. Los usuarios pueden migrar manualmente las configuraciones de lanzamiento en su espacio de trabajo desde la página de preferencias Ejecutar/depurar > Lanzamiento > Configuraciones de lanzamiento pulsando el botón Migrar.

Se ha añadido un atributo delegado de migración opcional nuevo al punto de extensión launchConfigurationTypes, especificando una clase que implemente la interfaz nueva ILaunchConfigurationMigrationDelegate. Un delegado de migración es responsable de identificar los candidatos a la migración y de migrarlos.

Modalidades de lanzamiento

Se ha añadido un atributo opcional nuevo al punto de extensión launchModes para soportar adecuadamente la externalización de las etiquetas de acción de menú de lanzamiento en cascada. Los clientes que contribuyen con modalidades de lanzamiento deben especificar la etiqueta adecuada para utilizarla en menús en cascada, como por ejemplo "Ejecutar como". El atributo nuevo se llama launchAsLabel. La plataforma proporciona etiquetas adecuadas para las modalidades de lanzamiento de ejecución, depuración y perfilado. Para la compatibilidad retroactiva, cuando no se especifica el atributo nuevo para una modalidad de lanzamiento, las etiquetas de menú en cascada se generan como antes, a través de MessageFormat con "{0} As". Consulte el problema relacionado 105235.

Componentes internacionales de Unicode para Java (ICU4J)

ICU4J es un conjunto de bibliotecas Java que proporciona un soporte exhaustivo de Unicode, globalización de software e internacionalización. Para proporcionar esta funcionalidad a la comunidad de Eclipse, se ha añadido ICU4J a la plataforma construida para Eclipse 3.2. Lo verá en la construcción como un plug-in llamado com.ibm.icu. La plataforma Eclipse utilizará las API de ICU en Eclipse 3.2.

Migración

La migración del código de la aplicación puede hacerse incrementalmente, lo que significa que la adopción de toda la función ICU4J no es necesaria para obtener los beneficios de la utilización de ICU4J. Consulte la página ICU4J en el wiki de Eclipse para obtener más detalles acerca de cómo migrar el código para utilizar ICU4J.

Plug-in de sustitución de ICU4J

La adición del plug-in de ICU4J añade unos 3MB a la huella. Algunas aplicaciones no desean absorber ICU4J si el tamaño de la aplicación tiene preferencia sobre la adopción de la función ICU4J. Si este es el caso, un plug-in de sustitución (com.ibm.icu.base) está disponible en la página de construcción de la plataforma Eclipse. Descargue el plug-in, saque el plug-in com.ibm.icu y la contrapartida origen del directorio /plugins y suéltelo en el plug-in de sustitución. Esto es necesario porque la plataforma Eclipse adoptó las API de ICU para 3.2 de forma que la simple eliminación del plug-in ICU generará errores de compilación en el código de la plataforma. El plug-in de sustitución tiene cerca de 100 KB y simplemente llama a la implementación predeterminada de JDK de las clases y las API utilizadas más comúnmente en ICU4J. De nuevo, puede leer la página ICU4J del wiki de Eclipse para obtener más detalles acerca de cómo utilizar el plug-in de sustitución de ICU.

Efecto sobre JFace: ViewerSorter y StructuredViewer

Para soportar ICU4J en JFace, se han necesitado algunos añadidos de API creativos para evitar hacer referencia a clases de ICU en la API. Esto ha provocado la adición de:

  1. una clase nueva llamada org.eclipse.jface.viewers.ViewerComparator de la que org.eclipse.jface.viewers.ViewerSorter es ahora una subclase.
  2. dos métodos nuevos a org.eclipse.jface.viewers.StructuredViewer para soportar la adición de org.eclipse.jface.viewers.ViewerComparator.

Base lógica

La clase ViewerSorter tiene un método público getCollator() que devuelve un java.text.Collator. Puesto que este método es una API, no se puede cambiar simplemente para utilizar Collator de ICU. Además, las clases de ICU no pueden ser parte de la API (signaturas) ya que una dependencia de plug-in directa en ICU evitaría que JFace se utilizar en modalidad autónoma (con SWT.) Para acomodar estas restricciones, se añadió la clase ViewerComparator que utiliza java.util.Comparator, en lugar de Collator de ICU. Esto se ha hecho porque la clase Collator de ICU implementa java.util.Comparator, de forma que cualquier StructuredViewer puede utilizar ahora Collator de ICU en lugar de java.text.Collator, pero JFace no tiene que añadir una dependencia del plug-in ICU4J. Los dos métodos nuevos añadidos a StructuredViewer soportan la utilización de Collator de ICU para ordenar el contenido del visor a través de un ViewerComparator en lugar de un ViewerSorter. Es recomendable que cualquier StructuredViewer utilice ahora estos métodos para obtener/establecer el ordenador del visor (comparador) en lugar de los métodosgetSorter() y setSorter(ViewerSorter).

División del entorno de ejecución

Nuevas API de entorno de ejecución

El paquete compuesto org.eclipse.equinox.common incluye varias clases de API nuevas (por ejemplo, Assert y ListenerList) que tienen nombres comunes. Si el código contiene una clase con el mismo nombre y utiliza sentencias import * para importar tanto las clases locales como las del entorno de ejecución, puede que reciba el siguiente mensaje de error:

   El tipo ABC es ambiguo
  

La organización de las importaciones y la elección del código fuente de importación adecuado deberían resolver este problema.

Vías de acceso de clases explícitas en los scripts de construcción personalizados

Como resultado del traslado del código a los nuevos plug-ins del entorno de ejecución, puede que los scripts personalizados que hagan referencia explícitamente a org.eclispe.core.runtime deban añadir uno o varios de los siguientes plug-ins: