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.
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.
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.
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.
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.
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.
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.
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:
org.eclipse.jface.viewers.ViewerComparator
de la que org.eclipse.jface.viewers.ViewerSorter
es ahora una subclase.
org.eclipse.jface.viewers.StructuredViewer
para soportar la adición de org.eclipse.jface.viewers.ViewerComparator
.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)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
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.
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: