Incompatibilidades entre Eclipse 2.1 y 3.0

Entre las versiones 2.1 y 3.0, Eclipse ha cambiado de forma que presenta incompatibilidades que afectan a los conectores. Los siguientes puntos describen las áreas que han cambiado y suministran instrucciones para migrar conectores de la versión 2.1 a la versión 3.0. Tenga en cuenta que sólo necesita consultarlos si experimenta problemas al ejecutar el conector 2.1 en 3.0.

  1. Versión de manifiesto de conector
  2. Reestructuración de los conectores de UI de la plataforma
  3. Reestructuración de los conectores de entorno de ejecución del núcleo de la plataforma
  4. Eliminación del conector Xerces
  5. Eclipse 3.0 tiene mayor simultaneidad
  6. Apertura de editores en IFiles
  7. Marcador de ir de editor
  8. Lanzador de editor
  9. Registro de editor
  10. Registro de ayuda de marcador de entorno de trabajo
  11. Proveedores de documentos de editor de texto
  12. Editores de texto
  13. Soporte de anotaciones sin cabecera
  14. Vista Consola
  15. Escuchadores de punto de interrupción Java
  16. Acceso de portapapeles en hebra de UI
  17. Eventos de tecla pulsada
  18. Transversal de pestañas de controles personalizados
  19. Orden de evento de selección en tabla SWT y widgets de árbol
  20. Nuevo nivel de gravedad en objetos de estado
  21. Notificaciones de cambios de recurso relativos a la construcción
  22. Notificaciones intermedias durante las operaciones de área de trabajo
  23. Extensiones de manejador de corriente de URL
  24. Orden de carga de clases
  25. Dominio de protección de cargador de clases no establecido
  26. Emisión de objeto PluginModel
  27. Implementación de ILibrary incompleta
  28. Suposiciones no válidas respecto al formato de los URL
  29. Métodos de BootLoader movidos/suprimidos
  30. La exportación de conector no incluye automáticamente los JAR del conector
  31. Volver a exportar API de entorno de ejecución
  32. Métodos de análisis de conector en Plataforma
  33. Bibliotecas de conectores suministradas por fragmentos
  34. Cambios en los scripts de construcción
  35. Cambios en la tarea Ant de construcción de PDE
  36. Cambios en la tarea Ant eclipse.build
  37. Cambios en la tarea Ant eclipse.fetch
  38. Sustitución de install.ini

1. Versión del manifiesto de conector

La cabecera de los archivos de manifiesto para conectores (y fragmentos de conector) ha cambiado para incluir una línea nueva que identifica la versión de manifiesto de conector adecuada. Antes de la versión 3.0, los conectores no tenían una de estas líneas <?eclipse ...?>; después de la 3.0, siempre deben tener una. Este cambio se ha realizado para que el entorno de ejecución de Eclipse reconozca de forma fiable conectores anteriores a la 3.0 que no se han portado a la 3.0, de forma que pueda proporcionar automáticamente una mayor compatibilidad binaria para tales conectores. Es el formato general del archivo plugin.xml (fragment.xml es similar):

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

Los manifiestos de conector creados por PDE 3.0 tienen este formato automáticamente. Se recomienda encarecidamente que utilice la herramienta de migración de conectores PDE. Inserta automáticamente la línea indicada en el manifiesto de conectores y fragmentos de conector de la versión 2.1 y se encarga de muchos de los otros cambios descritos aquí.

Si añade esta directiva a un archivo plugin.xml (manualmente o utilizando PDE), el archivo también debe actualizarse para listar explícitamente los conectores de los que depende. Por ejemplo, antes de Eclipse 3.0, las dependencias de org.eclipse.core.runtime y org.eclipse.core.boot eran implícitas. Con la versión 3.0, org.eclipse.core.boot ya no es necesario y los desarrolladores deben elegir org.eclipse.core.runtime u org.eclipse.core.runtime.compatibility (o ninguno de ellos) como el adecuado.

Nota: es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los conectores binarios de la versión 2.1.

2. Reestructuración de los conectores de UI de la plataforma

El conector org.eclipse.ui, que solía ser el conector principal de UI de plataforma, ahora sólo proporciona la API y los puntos de extensión para el entorno de trabajo genérico (es decir, no específico de IDE). La API y los puntos de extensión opcionales y específicos de IDE se han movido a otros conectores.

El impacto de este cambio es doble: (1) los puntos de extensión de org.eclipse.ui tienen nuevos ID de punto de extensión; y (2) la lista de conectores necesarios ha cambiado.

Los puntos de extensión de org.eclipse.ui de la tabla siguiente se han movido a conectores diferentes, haciendo que cambien sus ID de punto de extensión. Si un conector existente contribuye con una extensión a los puntos de extensión movidos, la referencia del atributo "point" del elemento <extension> del archivo de manifiesto de conector debe modificarse para que haga referencia a los nuevos ID de punto de extensión correspondientes. La herramienta de migración de conectores PDE realiza estos arreglos.

Nota: es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los conectores binarios de la versión 2.1. El entorno de ejecución de Eclipse 3.0 detecta automáticamente conectores anteriores a la versión 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> antes mencionada en el manifiesto de conector) y compensa automáticamente estos cambios de puntos de extensión y dependencias de conector.

ID de punto de extensión antiguo

ID de punto de extensión nuevo

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.editors.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.editors.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.editors.markerAnnotationSpecification

La tabla siguiente lista los paquetes API proporcionados anteriormente por el conector org.eclipse.ui que se han movido a otros conectores diferentes. (Los nombres de los paquetes, clases, campos y métodos API no han cambiado.) En algunos casos, los paquetes API se dividen entre más de un conector. Dado que las clases API visibles para cualquier conector dado se determinan por la lista de conectores necesarios de ese conector, estos cambios pueden necesitar que se ajusten elementos "<requires>" en un manifiesto de un conector existente para recuperar el acceso a la clase API.

Este cambio sólo afecta a los conectores que dependen del conector org.eclipse.ui (es decir, incluye <import plugin="org.eclipse.ui"/> en la sección <requires> del manifiesto de conector); todos los demás conectores no se ven afectados. Si está afectado, tal vez tenga que cambiar el elemento <import> o añadir elementos <import> adicionales para que todas las clases API que el conector necesiten estén dentro del ámbito. Recomendamos encarecidamente que los conectores sólo afirmen dependencias en los conectores que usan realmente. La inclusión de dependencias innecesarias reduce el rendimiento del entorno de ejecución porque el cargador de clases Java debe buscar clases en todos los dependientes. (La herramienta de migración de conectores PDE arreglará las dependencias y ayuda a determinar un conjunto mínimo.)

Paquete de API

Conector de 2.1

Conector(es) de 3.0 correspondiente(s)

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. Reestructuración de los conectores de entorno de ejecución del núcleo de la plataforma

El entorno de ejecución de plataforma de Eclipse 3.0 se basa en OSGi, por lo que son necesarios cambios en la estructura de los dos conectores de entorno de ejecución de la plataforma, org.eclipse.core.runtime y org.eclipse.core.boot.

Un nuevo conector, org.eclipse.core.runtime.compatibility, proporciona un puente de implementación entre las API antiguas y nuevas y es el nuevo lugar donde se hallan muchas de las API obsoletas que antes se encontraban en org.eclipse.core.runtime y org.eclipse.core.boot. Los puntos de extensión del entorno de ejecución de plataforma no están afectados por esta reestructuración.

Al migrar el conector existente a la versión 3.0, tiene que actualizarse el manifiesto del conector para reflejar la nueva estructura de conectores del entorno de ejecución de plataforma de Eclipse. Si es necesario, la herramienta de migración de manifiestos de conectores PDE añadirá una dependencia a org.eclipse.core.runtime.compatibility.

Tenga en cuenta también que, si marca el conector como 3.0 (utilizando <?eclipse version="3.0"?>) y el conector define una clase Plugin, debe realizar la siguiente importación de manera explícita, <import plugin="org.eclipse.core.runtime.compatibility"/> en el manifiesto de conector o asegurarse de que la clase Plugin define el constructor por omisión.

Nota: ésta es una de las incompatibilidades que no influye en cómo Eclipse 3.0 ejecuta los conectores binarios 2.1. El entorno de ejecución de Eclipse 3.0 detecta automáticamente los conectores de una versión previa a la 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> en el manifiesto de conector) y compensa automáticamente por estos cambios al entorno de ejecución de plataforma.

4. Eliminación del conector Xerces

El conector org.eclipse.xerces ya no es necesario y ha sido suprimido. El soporte de análisis de XML está incorporado a J2SE 1.4 y la presencia del conector Xerces crea conflictos de cargadores de clases. Los paquetes de API javax.xml.parsers, org.w3c.dom.* y org.xml.sax.*, proporcionados anteriormente por el conector org.eclipse.xerces, están ahora disponibles en las bibliotecas J2SE.

Si su conector necesita el conector org.eclipse.xerces, debe cambiar el manifiesto del conector para eliminar esta dependencia indicada. Una vez hecho esto, el código del conector debería compilarse y ejecutarse sin cambios adicionales.

Los conectores binarios 2.1 con una dependencia indicada del conector org.eclipse.xerces echarán en falta un requisito previo al ejecutarse en una configuración Eclipse 3.0 estándar. Como consecuencia de ello, el conector no se activará.

5. Eclipse 3.0 tiene mayor simultaneidad

Antes de Eclipse 3.0, Eclipse funcionaba casi siempre en una sola hebra. La mayor parte de los métodos y puntos de extensión operaban en la hebra de UI o en una hebra generada a partir de un diálogo de progreso que bloqueaba la hebra de UI. La mayor parte de escritores de conectores no tenían que preocuparse mucho por la seguridad de las hebras, aparte de asegurarse de que toda la actividad de la UI tuviera lugar en la hebra de UI. En Eclipse 3.0, hay en general mucha más simultaneidad. Numerosas operaciones tienen lugar en una hebra de segundo plano, donde pueden ejecutarse simultáneamente con otras hebras, incluida la hebra de UI. Todos los conectores cuyo código se ejecuta en una hebra de segundo plano deben ser conscientes a hora de la seguridad de hebras de su código.

Además de los conectores que ejecutan operaciones explícitamente en segundo plano mediante la API org.eclipse.core.runtime.jobs, hay varios recursos y puntos de extensión de API de plataforma que utilizan las hebras de segundo plano. Los conectores que se enganchan a estos recursos tienen que asegurarse de que su código tiene seguridad de hebras. La siguiente tabla resume la API y los puntos de extensión que ejecuten todo su código o una parte del mismo en una hebra de segundo plano en Eclipse 3.0:

Punto de extensión o clase API

Notas

org.eclipse.core.runtime.IRegistryChangeListener Nuevo en Eclipse 3.0, se ejecuta en segundo plano
org.eclipse.core.resources.IResourceChangeListener Eventos AUTO_BUILD ahora en segundo plano
org.eclipse.core.resources.builders (punto ext.) Construcción automática ahora en segundo plano
org.eclipse.core.resources.ISaveParticipant SNAPSHOT ahora en segundo plano
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (punto ext.) Nuevo en Eclipse 3.0, se ejecuta en segundo plano
org.eclipse.ui.decorators (punto ext.) Ya en segundo plano en Eclipse 2.1
org.eclipse.ui.startup (punto ext.) Ya en segundo plano en Eclipse 2.1
org.eclipse.team.core.org.eclipse.team.core.repository (punto ext.) Muchas operaciones ahora en segundo plano
org.eclipse.team.ui.synchronizeParticipants (punto ext.) Nuevo en Eclipse 3.0, se ejecuta en segundo plano
org.eclipse.debug.core.launchConfigurationTypes (punto ext.) Se ejecuta ahora en segundo plano
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD se ejecuta ahora en segundo plano, POST_RECONCILE ya se ejecutaba en segundo plano

Hay varias estrategias disponibles para que el código tenga seguridad de hebras. Una solución ingenua consiste en asegurarse de que todo el trabajo se realice en la hebra de UI, asegurando así una ejecución serializada. Es un enfoque frecuente en los conectores de UI que no realizan un proceso de uso intensivo de la CPU. Si hace esto, tenga en cuenta el riesgo de generar un punto muerto que es inherente a Display.syncExec. Display.asyncExec es generalmente más seguro, ya que no introduce el riesgo de punto muerto, al precio de perder el control exacto sobre el momento en que se ejecuta el código.

Otras técnicas para que el código tenga seguridad de hebras son, entre otras, las siguientes:

6. Apertura de editores en IFiles

Los métodos siguientes se suprimieron de la interfaz org.eclipse.ui.IWorkbenchPage. IWorkbenchPage está declarado en el entorno de trabajo genérico, pero los métodos son, de forma inherente, específicos de cada recurso.

Los clientes de estos métodos IWorkbenchPage.openEditor deben llamar a los métodos estáticos públicos correspondientes que se han declarado en la clase org.eclipse.ui.ide.IDE (en el conector org.eclipse.ui.ide).

Los clientes de estos métodos de IWorkbenchPage.openSystemEditor(IFile) deben convertir el IFile en un IEditorInput mediante nuevos FileEditorInput(IFile) y, a continuación, llamar al método openEditor(IEditorInput,String). En otras palabras, deben reescribir page.openSystemEditor(file) como page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Nota: los clientes que utilicen el ID de editor IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID deben pasar una entrada de editor que implemente org.eclipse.ui.IPathEditorInput (lo que efectúa FileEditorInput).

Nota: esta es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los conectores binarios 2.1. Eclipse 3.0 incluye un mecanismo de compatibilidad de entorno de ejecución binario que asegura que los binarios de conector 2.1 que utilicen cualquiera de los métodos suprimidos openEditor y openSystemEditor sigan funcionando como en 2.1 a pesar de este cambio de API. (Los métodos suprimidos son "añadidos de vuelta" efectivamente por el fragmento org.eclipse.ui.workbench.compatibility.)

7. Marcador goto de editor

El siguiente método se ha suprimido de la interfaz org.eclipse.ui.IEditorPart. IEditorPart está declarado en el entorno de trabajo genérico, pero el método es, de forma inherente, específico de cada recurso.

Los métodos correspondientes también se han suprimido de las clases del paquete org.eclipse.ui.part que implementan IEditorPart, es decir, EditorPart, MultiEditor, MultiPageEditorPart y MultiPageEditor. 

En su lugar, los clientes que llamen a este método deben probar si el componente de editor se implementa o adapta a org.eclipse.ui.ide.IGotoMarker (en el conector org.eclipse.ui.ide) y, en tal caso, llamar a gotoMarker(IMarker). La clase IDE tiene un método práctico para hacer esto: IDE.gotoMarker(editor, marker);

Los clientes que implementen un editor que puede situarse según la información de IMarker, deben implementarse o adaptarse a org.eclipse.ui.ide.IGotoMarker.

Dado que el único método de IGotoMarker es gotoMarker(IMarker) y tiene la misma firma y especificación que el antiguo IEditorPart.gotoMarker(IMarker), las implementaciones de editor existentes pueden adaptarse a este cambio simplemente incluyendo IGotoMarker en la cláusula de implementaciones de la definición de clase.

Un conector binario 2.1 con código que llame a este método obtendrá una excepción de error de enlace de clase cuando se ejecute en una configuración estándar de Eclipse 3.0.

8. Lanzador de editores

La interfaz del lanzador de editores org.eclipse.ui.IEditorLauncher se implementa mediante conectores que contribuyen a editores externos. El método siguiente se ha suprimido de esta interfaz. IEditorLauncher está declarado en el entorno de trabajo genérico, pero el método es, de forma inherente, específico de cada recurso.

Se ha sustituido por

En su lugar, los clientes que llamen a IEditorLauncher.open(file) deben llamar a IEditorLauncher.open(file.getLocation()). Los clientes que implementen esta interfaz deben sustituir (o aumentar) en uno su implementación de open(IFile) para open(IPath).

Un conector binario 2.1 con código que llame a este método obtendrá una excepción de error de enlace de clase cuando se ejecute en una configuración estándar de Eclipse 3.0.

9. Registro de editores

Los métodos siguientes se han eliminado de la interfaz org.eclipse.ui.IEditorRegistry. IEditorRegistry está declarado en el entorno de trabajo genérico, pero los métodos son, de forma inherente, específicos de cada recurso.

Los clientes que llaman a getEditors(file) o getImageDescriptor(file) deben llamar a los métodos equivalentes "String": Los clientes que llaman a setDefaultEditor(IFile archivo, String editorId) y getDefaultEditor(IFile file), en su lugar, deben llamar a los métodos estáticos públicos correspondientes que están declarados en la clase org.eclipse.ui.ide.IDE (en el conector org.eclipse.ui.ide): Además, se ha modificado el contrato de API para el método IEditorRegistrygetDefaultEditor(). Este método, que ahora también se ha desechado, siempre devolverá el descriptor de editor Editor externo de sistema. Este cambio influye en los clientes que daban por supuesto que el editor por omisión devuelto sería un editor de texto.

Hay constantes nuevas que representan los identificadores del editor externo de sistema y del editor del sistema in situ (SYSTEM_EXTERNAL_EDITOR_ID y SYSTEM_INPLACE_EDITOR_ID). Estos dos editores necesitan una entrada de editor que se implemente o se adapte a org.eclipse.ui.IPathEditorInput. Tenga en cuenta que el descriptor de editor in situ no existirá en las configuraciones de Eclipse que no den soporte a la edición in situ.

10. Registro de ayuda de marcadores de entorno de trabajo

El siguiente método se ha suprimido de la interfaz org.eclipse.ui.IWorkbench. IWorkbench está declarado en el entorno de trabajo genérico, pero el método es, de forma inherente, específico de cada recurso.

En su lugar, los clientes de IWorkbench.getMarkerHelpRegistry() deben llamar al método estático público org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (en el conector org.eclipse.ui.ide).

Un conector binario 2.1 con código que llame a este método obtendrá una excepción cuando se ejecute en una configuración estándar de Eclipse 3.0.

11. Proveedores de documentos de editor de texto

Para que org.eclipse.ui.texteditor.AbstractTextEditor sea independiente de IFile, org.eclipse.ui.texteditor.AbstractDocumentProvider introduce el concepto de una operación de proveedor de documentos (DocumentProviderOperation) y un ejecutor de operaciones de proveedor de documentos (IRunnableContext). Cuando se solicita que se realicen operaciones de restablecer, guardar o sincronizar, AbstractDocumentProvider crea operaciones de proveedor de documentos y utiliza el ejecutor de operaciones para ejecutarlas. El contexto ejecutable puede proporcionarse mediante subclases a través del método getOperationRunner. Este es un resumen de los cambios a los que los clientes deben adaptarse:

La subclase de AbstractDocumentProvider org.eclipse.ui.editors.text.StorageDocumentProvider implementa el método getOperationRunner para que siempre devuelva un valor nulo. Esto quiere decir que las subclases de StorageDocumentProvider no deben verse afectadas por este cambio.

La subclase de StorageDocumentProvider org.eclipse.ui.editors.text.FileDocumentProvider implementa el método getOperationRunner que devuelve un IRunnableContext para ejecutar el DocumentProviderOperations dado en WorkspaceModifyOperation. Otros cambios realizados en FileDocumentProvider son:

12. Editores de texto

Cambios en org.eclipse.ui.texteditor.AbstractTextEditor:

La subclase de AbstractTextEditor org.eclipse.ui.texteditor.StatusTextEditor proporciona el método de predicado isErrorStatus(IStatus). Las subclases pueden alterarlo temporalmente para decidir si un estado determinado debe considerarse como un error o no.

Cambios en org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Soporte de anotaciones sin cabecera

Como parte de la introducción al soporte de anotaciones sin cabecera, se han realizado los siguientes cambios en Annotation:

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. Vista Consola

Eclipse 3.0 tiene un nuevo soporte genérico de consola. La consola genérica está disponible a través de Ventana > Mostrar vista > Básica > Consola, y se utiliza por la depuración de Eclipse y la integración de Ant.

El ID de vista de la consola se ha cambiado de org.eclipse.debug.ui.ConsoleView a org.eclipse.ui.console.ConsoleView. Los conectores 2.1 que abren la consola programáticamente no funcionarán de manera satisfactoria, ya que la vista antigua ya no existe.

15. Escuchadores de punto de interrupción Java

En 3.0, los tipos de retorno correspondientes a los métodos org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) e installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) ha cambiado de booleano a int para permitir que los escuchadores voten "no importa". En los releases anteriores a 3.0, los escuchadores sólo podían votar "suspender" o "no suspender" cuando se acertaba un punto de interrupción, e "instalar" o "no instalar" cuando estaba a punto de instalarse un punto de interrupción. En 3.0, los escuchadores también pueden votar "no importa" para cualquiera de estas notificaciones. Esto permite que los clientes sólo tengan un voto decisivo en las situaciones que les importan. Para las notificaciones "acierto de punto de interrupción", el punto de interrupción se suspenderá si cualquier escuchador vota "suspender" o todos los escuchadores votan "no importa"; y no se suspenderá si al menos un escuchador vota "no suspender" y ningún escuchador vota "suspender". De forma similar, para las notificaciones de "punto de interrupción al instalar", el punto de interrupción se instalará si cualquier escuchador vota instalar, o si todos los escuchadores votan "no importa"; y no se instalará si al menos un escuchador vota "no instalar" y ningún escuchador vota "instalar". En general, los implementadores deben devolver el valor "no importa" (DONT_CARE) a menos que tengan una opinión tajante en un sentido u otro. Por ejemplo, es importante tener en cuenta que votar "suspender" prevalecerá sobre el voto de cualquier otro escuchador que sea "no suspender".

La interfaz IJavaBreakpointListener la implementan clientes que crean o reaccionan a puntos de interrupción en código Java. Probablemente hay pocos clientes más allá del propio JDT, salvo el que informó del problema (error 37760) que tengan remedio con este cambio. Es un cambio radical respecto al código existente que implementa la interfaz IJavaBreakpointListener. Este código tiene que modificarse para devolver un valor int adecuado antes de compilarse o ejecutarse en la versión 3.0.

16. Acceso del portapapeles en la hebra de UI

Antes de la versión 3.0, estaba permitido tácitamente que los métodos de la clase SWT org.eclipse.swt.dnd.Clipboard se ejecutasen en hebras distintas de la hebra de UI. Este descuido causaba anomalías en GTK, donde el sistema operativo requiere que todas las interacciones con el portapapeles se realicen en la hebra de UI. El descuido no se descubrió antes porque muchas aplicaciones tienen una sola hebra y reciben la mayor parte de sus pruebas en Windows. Para que la API Clipboard sea sostenible y funcione entre plataformas, en 3.0 la especificación e implementación de todos los métodos de API Clipboard se han modificado para lanzar una excepción SWT (ERROR_THREAD_INVALID_ACCESS) si se invocan desde una hebra que no sea la de UI. Los componentes de Eclipse proporcionan automáticamente los servicios de portapapeles como, por ejemplo, el editor de texto, los que aísla a muchos clientes de este cambio radical. El código existente que realiza un uso directo de Clipboard debe asegurarse de que los métodos de API se llamen en la hebra correcta, utilizando Display.asyncExec o syncExec cuando sea apropiado para desplazar los accesos a la hebra de UI.

17. Eventos de pulsación de tecla

En la versión 3.0, SWT informa de los eventos de pulsación de tecla antes de que se realice el trabajo en el OS. Esto es mucho antes de lo que se hacía antes de 3.0. Este cambio se ha realizado para dar soporte a los enlaces de teclas en Eclipse que necesitan eventos de tecla de intercepción antes de que un widget tenga la oportunidad de procesar el carácter. Las consecuencias de este cambio son visibles para el código que maneja directamente los eventos org.eclipse.swt.SWT.KeyDown de bajo nivel. Por ejemplo, quiere decir que, cuando un escuchador en un widget Text recibe un evento de pulsación de tecla, el contenido del widget (getText()) no incluirá todavía la tecla que acabarse de pulsarse (que es lo que habría hecho antes de la versión 3.0). La manera recomendada de obtener el texto completo del widget, incluida la tecla actual, es manejar los eventos SWT.Modify o SWT.Verify de nivel superior, en vez del evento SWT.KeyDown de nivel inferior; el código que ya lo haga de esta manera no se verá afectado por este cambio.

18. Cruce de pestañas de controles personalizados

Antes de la versión 3.0, cuando el foco estaba en la clase SWT org.eclipse.swt.widgets.Canvas o en una de sus subclases (incluidos los widgets personalizados), al pulsar Control+Tabulador, Mayúsculas+Tabulador, Control+RePág o Control+AvPág se desencadenaba automáticamente el cruce al widget siguiente/anterior sin informar de un evento de tecla. Este comportamiento no estaba especificado y es contrario a la regla de que los Canvas ven todas las teclas que se pulsan en ellos. La manera adecuada de manejar el cruce es registrando un escuchador de cruce. Para dar un soporte adecuado a los enlaces de teclas de Eclipse en la versión 3.0, el comportamiento por omisión se ha modificado, de manera que ahora Canvas ve los eventos de tecla Control+Tabulador, Mayúsculas+Tabulador, Control+RePág o Control+AvPág en vez de cruzar. Si utiliza un Canvas sin formato o define una subclase de Canvas, asegúrese de que registra un escuchador de cruce.

19. Orden de eventos Selection en tabla SWT y widgets de árbol

Las selecciones de ratón de elementos de las clases SWT org.eclipse.swt.widgets.Table y Tree generan la secuencia de eventos MouseDown-Selection-MouseUp de manera uniforme en todos los entornos operativos. De forma similar, las selecciones de teclado generan la secuencia de eventos KeyDown-Selection-KeyUp de manera uniforme en todos los entornos operativos. Antes de la versión 3.0, el orden de eventos no era uniforme y Motif y Photon discrepaban del resto al informar siempre del evento Selection en primer lugar; es decir, Selection-MouseDown-MouseUp o Selection-KeyDown-KeyUp. Para la versión 3.0, el orden de eventos en Motif y Photon se ha cambiado para que coincida con los otros. El código existente que funcionaba correctamente en {Windows, GTK} y en {Motif, Photon} es poco probable que se vea afectado. Sin embargo, es una buena idea comprobar el código para asegurarse de que no se basa en un orden de eventos no válido.

20. Nuevo nivel de gravedad en los objetos de estado

org.eclipse.core.runtime.IStatus tiene una nueva constante de gravedad, IStatus.CANCEL, que puede utilizarse para indicar la cancelación. Esta adición afecta a los llamadores de IStatus.getSeverity() que se basan en que el conjunto de gravedades posibles está limitado a IStatus.OK, INFO, WARNING y ERROR. Los llamadores de getSeverity deben actualizar su código para incluir la nueva gravedad.

21. Notificaciones de cambio de recursos relacionadas con la construcción

En Eclipse 3.0, las construcciones automáticas de área de trabajo tienen lugar ahora en una hebra de segundo plano. Esto necesitó un cambio de contrato de API a org.eclipse.core.resources.IResourceChangeEvent. Antes, el contrato de IResourceChangeEvent garantizaba el orden siguiente de eventos para todos los cambios del área de trabajo:

  1. Notificación de eventos PRE_DELETE o PRE_CLOSE si era pertinente
  2. Realizar la operación
  3. Notificación de eventos PRE_AUTO_BUILD
  4. Si la construcción automática está activada, realizar construcción incremental de área de trabajo
  5. Notificación de evento POST_AUTO_BUILD
  6. Notificación de evento POST_CHANGE

Ahora, la construcción automática se ejecuta en segundo plano y ya no hay garantías sobre la relación temporal entre los eventos AUTO_BUILD y el evento POST_CHANGE. En Eclipse 3.0, los pasos 3-5 de la estructura anterior se eliminan de la operación. La imagen resultante tiene el aspecto siguiente:

  1. Notificación de eventos PRE_DELETE o PRE_CLOSE si era pertinente
  2. Realizar la operación
  3. Notificación de evento POST_CHANGE

Periódicamente, la plataforma realizará una operación de construcción de área de trabajo en segundo plano. Tenga en cuenta que esto sucederá independientemente de si la construcción automática está activada o desactivada. El periodo de tiempo exacto en que se realizará esta construcción no se especificará. La estructura de la operación de construcción tendrá el aspecto siguiente:

  1. Notificación de evento PRE_BUILD (PRE_BUILD es el nuevo nombre de PRE_AUTO_BUILD)
  2. Si la construcción automática está activada, realizar construcción incremental de área de trabajo
  3. Notificación de evento POST_BUILD (POST_BUILD es el nuevo nombre de POST_AUTO_BUILD)
  4. Notificación de evento POST_CHANGE

El punto de referencia de los deltas recibidos por los escuchadores de construcción automática será distinto del de los escuchadores posteriores al cambio. Los escuchadores de construcción recibirán la notificación de todos los cambios desde el fin de la última operación de construcción. Los escuchadores posteriores al cambio recibirán un delta que describirá todos los cambios efectuados desde la última notificación posterior al cambio. Esta nueva estructura retiene tres características de los escuchadores de cambio de recursos que han sido válidas desde Eclipse 1.0:

No obstante, hay algunas diferencias importantes respecto a este enfoque. Antes de Eclipse 3.0, se llamaba siempre a los escuchadores de construcción automática antes que a los escuchadores POST_CHANGE. Por esta razón, el delta recibido por los escuchadores de construcción automática era siempre un subconjunto del delta recibido por los escuchadores POST_CHANGE. Esta relación, esencialmente, se ha invertido. Los escuchadores de construcción automática recibirán un delta que es un superconjunto de todos los deltas proporcionados por los escuchadores POST_CHANGE desde el fin de la última construcción en segundo plano. Como antes, se permitirá a los escuchadores de construcción automática que modifiquen el área de trabajo, mientras que los escuchadores posteriores al cambio no podrán hacerlo.

Ya no será válido que, al completarse una operación de cambio de área de trabajo, los escuchadores de evento AUTO_BUILD recibirán una notificación. Es poco probable que este cambio afecte al código cliente que registra los escuchadores de cambios de recursos con IWorkspace.addResourceChangeListener(IResourceChangeListener), porque los eventos AUTO_BUILD no se notificaron nunca a estos escuchadores. No obstante, es probable que los clientes que utilicen IWorkspace.addResourceChangeListener(IResourceChangeListener,int) y especifiquen una máscara de evento que incluya eventos AUTO_BUILD se vean interrumpidos a causa de este cambio si han hecho suposiciones sobre cuándo se ejecutarán los escuchadores de construcción automática o en qué hebra se ejecutarán. Por ejemplo, si un escuchador de construcción automática actualiza un modelo de dominio para reflejar cambios en el área de trabajo, es posible que esta actualización no se haya producido al devolverse la operación de cambio de área de trabajo. Vale la pena indicar que sólo el código de UI puede verse afectado de esta manera. El código de nivel de núcleo que se llame a través de API puede llamarse dentro del ámbito de un IWorkspaceRunnable, de manera que nunca podrá saber con seguridad cuándo se llamará a los escuchadores de cambios de recursos. El arreglo sugerido para esta interrupción consiste en utilizar POST_CHANGE en lugar de escuchadores de construcción, si es necesario que haya una notificación antes de que se complete la operación.

22. Notificaciones intermedias durante las operaciones de área de trabajo

Ya no está garantizado que todos los cambios de recursos que se produzcan durante el ámbito dinámico de un IWorkspaceRunnable se procesarán por lotes en una única notificación. Este mecanismo puede seguir siendo utilizando para procesar cambios por lotes, a fin de evitar construcciones y notificaciones innecesarias, pero ahora la plataforma puede decidir realizar notificaciones durante la operación. No es probable que este cambio de contrato de API represente un cambio radical para los clientes existentes. Es equivalente a que la plataforma decida llamar a IWorkspace.checkpoint periódicamente durante una operación de ejecución larga. La razón de este cambio es que ahora es posible que varias hebras modifiquen el área de trabajo simultáneamente. Cuando una hebra termina de modificar el área de trabajo, es necesaria una notificación para evitar problemas de capacidad de respuesta, aunque la otra operación no se haya completado todavía. Este cambio permite también a los usuarios empezar a trabajar en un conjunto de recursos antes de que se complete la operación. Por ejemplo, ahora un usuario puede empezar a examinar archivos de un proyecto que está aún en proceso de reserva. El nuevo método IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) tiene un distintivo opcional, AVOID_UPDATE, que las operaciones pueden utilizar como pista para la plataforma con el fin de especificar si se desea realizar actualizaciones periódicas.

23. Extensiones de manejador de corriente de URL

Elementos afectados: los conectores que añaden extensiones al punto de extensión org.eclipse.core.runtime.urlHandlers.

Descripción: el contrato del punto de extensión org.eclipse.core.runtime.urlHandlers se ha cambiado para utilizar el servicio URL Stream Handler proporcionado por OSGi. El soporte de OSGi es superior al de Eclipse 2.1 y maneja correctamente los manejadores dinámicos. Debido a los diversos problemas de diseño con el mecanismo básico de manejador URL de Java, el URLStreamHandlers registrado con el servicio de manejador OSGi debe implementar org.osgi.service.url.URLStreamHandlerService.

Acción necesaria: antes, la clase de manejadores tenía que implementar java.net.URLStreamHandler y ampliar el punto de extensión urlHandlers. El punto de extensión ya no está soportado y el manejador debe actualizarse para implementar la interfaz org.osgi.service.url.URLStreamHandlerService. La infraestructura OSGi proporciona una clase básica abstracta (org.osgi.service.url.AbstractURLStreamHandlerService) que puede generar una subclase superficialmente para cumplir este cometido.

En vez de registrar el manejador mediante un punto de extensión, ahora los conectores deben hacerlo registrando su manejador como un servicio. Por ejemplo:

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. Orden de carga de clases

Elementos afectados: los conectores que suministran paquetes proporcionados, que también son suministrados por otros conectores. Un número muy limitado de conectores está afectado por este cambio y algunos de los afectados se beneficiarán del mismo (vea a continuación).

Descripción: En Eclipse 2.x, los cargadores de clases buscan clases en el orden siguiente: consulte (1) cargador de clases padre (en la práctica, es el cargador de clases de arranque Java); a continuación, (2) su propio contenido de vía de acceso de clase (classpath) y, finalmente, (3) todos sus requisitos previos en el orden declarado. OSGi ofrece una optimización de este modelo. En este enfoque, un cargador de clases consultará (1) un cargador de clases padre (de nuevo, en la práctica es el cargador de clases de arranque Java), a continuación (2a) un único requisito previo conocido por contribuir con clases en el paquete que se consulta, o (2b) sus propias entradas de vía de acceso de clase (classpath) para la clase deseada.

El cargador de clases determina si se consulta a sí mismo o a sus requisitos previos, basándose en sus paquetes importados y obligatorios. Esta información se deduce del contenido de conector en el caso de los conectores tradicionales y se especifica directamente en el caso de los conectores que tienen un manifiesto de paquete OSGi explícito. En cualquiera de ambos casos se conoce a priori qué cargadores de clases suministrarán las clases para cada paquete. Esto ofrece mejoras en el rendimiento, así como una solución al difícil problema de que varios requisitos previos contribuyan a las mismas clases.

Vea, por ejemplo, el caso de Xerces y Xalan, en que ambos contienen diversas clases de paquetes org.xml. Si utiliza el primer enfoque, el conector Xerces verá su propia copia de estas clases, mientras que el conector Xalan verá la copia de las mismas. Dado que estos conectores, tienen que comunicarse, se producen ClassCastExceptions. Si utiliza el segundo enfoque, sólo uno de los conectores contribuye a las clases duplicadas y ambos conectores verán las mismas copias.

Acción necesaria: la acción necesaria depende de los detalles particulares del caso. Los desarrolladores afectados tendrán que revisar su vía de acceso de clases y solucionar los conflictos que puedan producirse.

25. Dominio de protección de cargador de clases no establecido

Elementos afectados: los conectores que esperan que el dominio de protección de su cargador de clases esté establecido en todo momento.

Descripción: en Eclipse 2.1, los cargadores de clases de conector eran java.security.SecureClassloaders y, como tales, siempre tenían establecido un dominio de protección. En Eclipse 3.0, los cargadores de clases no amplían SecureCassloader y sólo establecen el dominio de protección si se activa la seguridad Java (no es lo normal).

Acción necesaria: la acción necesaria dependerá de la situación en que el conector utilice el dominio de protección.

26. Difusión de objetos PluginModel

Elementos afectados: los conectores que difunden objetos del tipo org.eclipse.core.runtime.IPlugin* a org.eclipse.core.runtime.model.Plugin*Model. Aunque la relación entre estas interfaces y las clases de modelo no está especificada en la API de Eclipse 2.1, solicitamos explícitamente este cambio porque encontramos casos de conectores que se basaban en esta relación en la implementación 2.1.

Descripción: la API de Eclipse proporciona una serie de interfaces (por ejemplo, IPluginDescriptor) y las llamadas clases "modelo" (por ejemplo, PluginDescriptorModel) relacionadas con conectores y el registro de conectores. En la implementación de Eclipse 2.1, ocurre que la clases de modelo implementan las interfaces relevantes. En el nuevo entorno de ejecución basado en OSGi, el registro de conectores se ha reelaborado de manera significativa para permitir que exista una separación entre los aspectos de carga de clases y requisitos previos de los conectores y los aspectos de extensión y de punto de extensión. Como tal, el entorno de ejecución de Eclipse 3.0 no puede mantener la relación de implementación presente en la versión 2.1.

Acción necesaria: es necesario reelaborar el código de los conectores que se basan en esta relación que no es de API de acuerdo a cada caso. Se proporciona más información al respecto en la sección de cambios recomendados de este documento y en el Javadoc de clases y métodos relacionados.

27. Implementación de ILibrary incompleta

Elementos afectados: los conectores que utilizan org.eclipse.core.runtime.ILibrary.

Descripción: el nuevo entorno de ejecución mantiene las entradas de vía de acceso de clases (classpath) en un formato diferente e incompatible de Eclipse. Como resultado, la capa de compatibilidad no puede modelar correctamente las estructuras OSGi subyacentes como objetos ILibrary. El soporte de compatibilidad del entorno de ejecución crea objetos ILibrary pero debe suponer valores por omisión para todo excepto para la vía de acceso de la biblioteca.

Acción necesaria: los usuarios de ILibrary deben estudiar el acceso a los valores de cabecera deseados (por ejemplo, Bundle-Classpath) desde el Bundle adecuado (vea Bundle.getHeaders()) y utilizando la clase de ayuda ManifestElement para interpretar las entradas. Consulte el Javadoc sobre clases para obtener más detalles.

28 Suposiciones no válidas respecto al formato de URL

Elementos afectados: los conectores que hacen suposiciones respecto a su estructura de instalación, ubicación y el diseño del sistema de archivos local.

Descripción: métodos tales como IPluginDescriptor.getInstallURL() devuelven los URL en un formato específico. A pesar de que no se especifique su formato, varios conectores hacen suposiciones basadas en la implementación actual. Por ejemplo, tal vez esperen obtener un URL file: y utilicen URL.getFile() y la manipulación java.io.File en el resultado. Hasta la fecha, este ha sido un enfoque válido pero bastante frágil. Por ejemplo, si se instala un conector en un servidor web, es posible que se devuelva un URL del tipo http:. El nuevo entorno de ejecución de Eclipse 3.0 es aún más flexible y abre más posibilidades para las configuraciones de ejecución (por ejemplo, mantener conectores enteros en los archivos JAR en vez de desplegarlos en directorios). Es decir, mientras que el nuevo entorno de ejecución basado en OSGi no quiebra la API de la versión 2.1, expone más casos en que las suposiciones realizadas en los conectores actuales no son válidas.

Acción necesaria: los escritores de conectores deben asegurarse de que la información para la que necesitan tener acceso está disponible a través de getResource() (y está en la vía de acceso de clases) o que utilizan la API pertinente para acceder al contenido de un conector (por ejemplo, Bundle.getEntry(String)).

29. Métodos BootLoader trasladados/suprimidos

Elementos afectados: el código que no es de conector y que llama a ciertos métodos desde la clase org.eclipse.core.boot.BootLoader.

Descripción: los métodos estáticos BootLoader.startup(), shutdown() y run() se han trasladado a org.eclipse.core.runtime.adaptor.EclipseStarter, que forma parte de la infraestructura de OSGi. Esta API es la interfaz entre main() de startup.jar y el entorno de ejecución de infraestructura de OSGi/Eclipse. La reestructuración del entorno de ejecución no ha permitido que estos métodos permanecieran en BootLoader. La antigua clase BootLoader está ubicada ahora en la capa de compatibilidad de entorno de ejecución y se ha desechado, y los métodos trasladados están en un apéndice y no harán nada.

No hay sustituto para el antiguo BootLoader.getRunnable(), ya que el entorno de ejecución ya no puede dar soporte a la adquisición de aplicaciones individuales. En su lugar, los usuarios deben indicar la aplicación que les interesa cuando inicien la plataforma.

Acción necesaria: En general, esta API la utilizan muy pocos usuarios (no puede utilizarse desde un conector Eclipse). En el raro caso en que así sea, el código debe adaptarse para utilizar los métodos correspondientes en EclipseStarter.

30. La exportación de conector no incluye automáticamente los JAR del conector

Elementos afectados: todos los conectores.

Descripción: en Eclipse 2.1, la línea bin.includes de un conector de su build.properties no tenía que contener la lista de los archivos JAR de su declaración de biblioteca en el archivo plugin.xml; estos archivos JAR se añadían automáticamente. En Eclipse 3.0, la lista de archivos de la sección bin.includes de build.properties es una lista exhaustiva y debe incluir todos los archivos que los desarrolladores de conectores tienen previsto incluir en su conector al construirlo o exportarlo.

Acción necesaria: asegúrese de que la línea bin.includes del archivo build.properties incluya todos los archivos JAR listados en el archivo plugin.xml.

31. Volver a exportar API de entorno de ejecución

Elementos afectados: los conectores que exponen una API que incluye elementos de la API de entorno de ejecución cambiada.

Descripción: varios conectores que exponen una API que incluye elementos de la API de entorno de ejecución. Con los cambios efectuados en el entorno de ejecución de Eclipse 3.0 que se resumen aquí, los conectores de cliente deben volver a evaluar su uso de la API de entorno de ejecución en su propia API.

Acción necesaria: esta situación es muy rara, ya que ha cambiado una parte muy pequeña de la API de entorno de ejecución de Eclipse. Según cuál sea la situación, puede que los clientes tengan que cambiar su API o seguir basándose en la capa de compatibilidad.

32. Métodos de análisis de conector en Platform

Elementos afectados: los conectores que utilizan org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Descripción: el método org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) se ha movido. La API asociada al argumento Factory se ha movido del conector org.eclipse.core.runtime hasta el conector org.eclipse.core.runtime.compatibility (que depende del conector de entorno de ejecución). Como resultado, también se ha movido el método de análisis.

Acción necesaria: los usuarios de este método deben utilizar el mismo método en la clase org.eclipse.core.runtime.model.PluginRegistryModel.

33. Bibliotecas de conectores suministradas por fragmentos

Elementos afectados: conectores que especifican código en su vía de accesos de clases (classpath) pero no suministran dicho código (es decir, el JAR está suministrado por un fragmento; por ejemplo, el conector org.eclipse.swt).

Descripción: el nuevo entorno de ejecución debe convertir los archivos plug.xml a archivos manifest.mf en segundo plano. Esto se realiza mediante una transformación mecánica directa y un análisis de los JAR listados y suministrados por el conector. En el caso de que un conector especifique un JAR en su vía de acceso de clases pero no proporcione el JAR, no habrá ningún código que analizar y el conversor de conectores no podrá generar un manifest.mf correcto.

Acción necesaria: los proveedores de estos conectores deben adaptarse para proporcionar el archivo JAR adecuado en el propio conector, o bien diseñar/mantener un archivo META-INF/MANIFEST.MF para su conector. Normalmente esto puede realizarse utilizando PDE para obtener el manifiesto original y luego añadir la cabecera Provide-Package adecuada.

34. Cambios en los scripts de construcción

Elementos afectados: Scripts (por ejemplo, archivos Ant build.xml) que definen vías de acceso de clases que contienen archivos JAR relacionados con el entorno de ejecución y directorios de clases.

Descripción: el nuevo entorno de ejecución contiene varios de los conectores y archivos JAR nuevos. Su introducción era obligatoria debido a la refactorización del entorno de ejecución en fragmentos configurables. En la mayor parte de situaciones de entorno de ejecución, estos cambios son transparentes. Sin embargo, si tiene scripts build.xml (o similares) personalizados que actualmente compilen código para org.eclipse.core.runtime, tendrá que actualizarlos antes de que puedan funcionar correctamente. Un script típico contiene una entrada de vía de acceso de clases (classpath) en una tarea <javac> que hace referencia al conector org.eclipse.core.runtime de la manera siguiente:

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

El conector de entorno de ejecución sigue conteniendo buena parte del código de entorno de ejecución original. Sin embargo, varios componentes del entorno de ejecución que sólo están ahí por razones de compatibilidad se encuentran en un conector de compatibilidad (org.eclispe.core.runtime.compatibility). La mayor parte del nuevo código de entorno de ejecución se halla contenido en una colección de conectores (org.eclipse.osgi.*).

Acción necesaria: los desarrolladores deben añadir las entradas siguientes como sea necesario para eliminar los errores de compilación. Aunque el conjunto completo de archivos JAR suministrado aparece en la lista incluida a continuación, normalmente sólo tendrá que utilizarse un subconjunto de los mismos en la vía de acceso de clases durante la compilación. Como es habitual, la inclusión de directorios /bin es a discreción del usuario. Las entradas se proporcionan aquí en grupos lógicos según el conector que los suministra:

Además, los JAR siguientes pueden ser necesarios en casos especiales:

Mientras actualice estos scripts, debe aprovechar la oportunidad para borrar (es decir, eliminar) todas las referencias a org.eclipse.core.boot. Este conector es obsoleto y ya no contiene código. Las entradas pueden dejarse en la vía de acceso de clases pero no sirven para nada y deberían eliminarse. Procure eliminar:

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. Cambios en la tarea Ant PDE Build

Elementos afectados: los scripts (por ejemplo, los archivos Ant build.xml) que utilizan la tarea eclipse.buildScript.

Descripción: PDE Build introdujo una nueva propiedad en la tarea eclipse.buildScript para controlar la generación de script de construcción de conectores. Esto era obligatorio a causa de la introducción del nuevo entorno de ejecución basado en OSGi.

Acción necesaria: si desea utilizar Eclipse 3.0 para construir un producto basado en 2.1, introduzca en eclipse.buildScript la propiedad "buildingOSGi" y establézcala en el valor false. Por ejemplo:

<eclipse.buildScript ... buildingOSGi="false"/>

36. Cambios en la tarea Ant eclipse.build

Elementos afectados: los scripts (por ejemplo, los archivos Ant build.xml) que utilicen la tarea eclipse.buildScript.

Descripción: PDE Build introdujo una nueva propiedad en la tarea eclipse.buildScript para controlar la generación de scripts de construcción de conectores. Esto era obligatorio a causa de la introducción del nuevo entorno de ejecución basado en OSGi.

Acción necesaria: si desea utilizar Eclipse 3.0 para construir un producto basado en 2.1, introduzca en eclipse.buildScript la propiedad "buildingOSGi" y establézcala en el valor false. Por ejemplo:

<eclipse.buildScript ... buildingOSGi="false"/>

37. Cambios en la tarea Ant eclipse.fetch

Elementos afectados: Scripts (por ejemplo, archivos Ant build.xml) utilizando la tarea eclipse.buildScript.

Descripción: PDE Build ha cambiado el comportamiento de la tarea eclipse.fetch para facilitar la construcción de Eclipse en un estilo de construcción automatizado. El estilo elements sólo da soporte ahora a una entrada cada vez y scriptName se pasa por alto siempre.

Acción necesaria: si tenía una lista de entradas en el código "elements" de una llamada eclipse.fetch, dispérselas en varias llamadas a eclipse.fetch. Si establece habitualmente scriptName, observe que ahora el script de captación generado se llama siempre "fetch_{elementId}". Por ejemplo:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

se convierte en

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. Sustitución de install.ini

El archivo install.ini ya no está incluido. En su lugar se encuentra el nuevo archivo config.ini en el subdirectorio de configuración. Los productos que utilizaban el archivo install.ini para especificar una característica primaria (por ejemplo, proporcionar información de marca) tienen que efectuar cambios en el archivo config.ini en su lugar. Además del nuevo nombre de archivo, los nombres de las claves han cambiado.

El valor de la clave feature.default.id en 2.1 debe establecerse como valor de la nueva clave eclipse.product. El valor de eclipse.application debe establecerse en "org.eclipse.ui.ide.workbench".

Finalmente, en 2.1 la imagen inicial siempre era splash.bmp en el directorio del conector de marca. En 3.0, la ubicación de la imagen inicial la proporciona explícitamente la clave osgi.splashPath en el archivo config.ini.