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.
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.
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 |
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.
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á.
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:
org.eclipse.core.runtime.jobs.ILock
.
La ventaja de los bloqueos ILock
sobre los bloqueos genéricos
radica en que transfieren automáticamente a la hebra de UI cuando realizan un
syncExec
y disponen de soporte de detección de puntos muertos
incorporado en su implementación que registra y resuelve los puntos muertos.
Display.asyncExec
), que se procesa por completo en la hebra de UI.
java.lang.String
y org.eclipse.core.runtime.IPath
. La
ventaja de los objetos inmutables es que tienen un acceso de lectura
extremadamente rápido, al precio de dar trabajo adicional con las
modificaciones.
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.)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.
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.
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
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.
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.
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.
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.
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.
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:
Cambios en org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
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:
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
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.
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.
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.
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.
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.
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.
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.
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:
PRE_DELETE
o PRE_CLOSE
si era pertinentePRE_AUTO_BUILD
POST_AUTO_BUILD
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:
PRE_DELETE
o PRE_CLOSE
si era pertinentePOST_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:
PRE_BUILD
(PRE_BUILD
es el nuevo nombre de PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
es el nuevo nombre de POST_AUTO_BUILD)
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:
POST_CHANGE
reciben una notificación de
absolutamente todos los cambios de recursos que se producen mientras están
registrados.
Esto incluye los cambios efectuados por los constructores y por otros
escuchadores.
PRE_AUTO_BUILD
reciben una notificación de
todos los cambios de recursos excepto los cambios efectuados por los
constructores y los escuchadores de cambios de recursos.
POST_AUTO_BUILD
reciben una notificación de
todos los cambios de recursos excepto los cambios efectuados por otros
escuchadores POST_AUTO_BUILD
.
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.
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.
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);
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.
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.
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.
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.
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)
).
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.
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.
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.
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
.
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.
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
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"/>
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"/>
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" .../>
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.