Entre las versiones 2.1 y 3.0, Eclipse ha cambiado de forma que presenta incompatibilidades que afectan a los plug-ins. Los siguientes puntos describen los espacios de trabajo que han cambiado y suministran instrucciones para migrar plug-ins de la versión 2.1 a la versión 3.0. Tenga en cuenta que solo necesita consultarlos si experimenta problemas al ejecutar el plug-in 2.1 en 3.0.
La cabecera de los archivos de manifiesto para plug-ins (y fragmentos de plug-in) ha cambiado para incluir una línea nueva que identifica la versión de manifiesto de plug-in adecuada. Antes de la versión 3.0, los plug-ins 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 plug-ins 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 plug-ins. 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 plug-in creados por PDE 3.0 tienen este formato automáticamente. Se recomienda encarecidamente que utilice la herramienta de migración de plug-ins PDE. Inserta automáticamente la línea indicada en el manifiesto de plug-ins y fragmentos de plug-in 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 plug-ins 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 plug-ins binarios de la versión 2.1.
El plug-in org.eclipse.ui, que solía ser el plug-in principal de UI de plataforma, ahora solo 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 plug-ins.
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 plug-ins necesarios ha cambiado.
Los puntos de extensión de org.eclipse.ui de la tabla siguiente se han movido a plug-ins diferentes, haciendo que cambien sus ID de punto de extensión. Si un plug-in 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 plug-in debe modificarse para que haga referencia a los nuevos ID de punto de extensión correspondientes. La herramienta de migración de plug-ins PDE realiza estos arreglos.
Nota: es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los plug-ins binarios de la versión 2.1. El entorno de ejecución de Eclipse 3.0 detecta automáticamente plug-ins anteriores a la versión 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> antes mencionada en el manifiesto de plug-in) y compensa automáticamente estos cambios de puntos de extensión y dependencias de plug-in.
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 plug-in org.eclipse.ui que se han movido a otros plug-ins 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 plug-in. Dado que las clases API visibles para cualquier plug-in dado se determinan por la lista de plug-ins necesarios de ese plug-in, estos cambios pueden necesitar que se ajusten elementos "<requires>" en un manifiesto de un plug-in existente para recuperar el acceso a la clase API.
Este cambio solo afecta a los plug-ins que dependen del plug-in org.eclipse.ui (es decir, incluye <import plugin="org.eclipse.ui"/> en la sección <requires> del manifiesto de plug-in); todos los demás plug-ins 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 plug-in necesiten estén dentro del ámbito. Recomendamos encarecidamente que los plug-ins solo afirmen dependencias en los plug-ins 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 plug-ins PDE arreglará las dependencias y ayuda a determinar un conjunto mínimo.)
Paquete de API |
Plug-in de 2.1 |
Plug-in(s) 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 plug-ins de entorno de ejecución de la plataforma, org.eclipse.core.runtime y org.eclipse.core.boot.
Un nuevo plug-in, 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 plug-in existente a la versión 3.0, tiene que actualizarse el manifiesto del plug-in para reflejar la nueva estructura de plug-ins del entorno de ejecución de plataforma de Eclipse. Si es necesario, la herramienta de migración de manifiestos de plug-ins PDE añadirá una dependencia a org.eclipse.core.runtime.compatibility.
Tenga en cuenta también que, si marca el plug-in como 3.0 (utilizando <?eclipse version="3.0"?>) y el plug-in 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 plug-in o asegurarse de que la clase Plugin define el constructor por omisión.
Nota: es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los plug-ins binarios de la versión 2.1. El entorno de ejecución de Eclipse 3.0 detecta automáticamente los plug-ins de una versión previa a la 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> en el manifiesto de plug-in) y compensa automáticamente por estos cambios al entorno de ejecución de plataforma.
El plug-in 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 plug-in 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 plug-in org.eclipse.xerces, están ahora disponibles en las bibliotecas J2SE.
Si su plug-in necesita el plug-in org.eclipse.xerces, debe cambiar el manifiesto del plug-in para eliminar esta dependencia indicada. Una vez hecho esto, el código del plug-in debería compilarse y ejecutarse sin cambios adicionales.
Los plug-ins binarios 2.1 con una dependencia indicada del plug-in 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 plug-in 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-in 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: es una de las incompatibilidades que no influyen en cómo Eclipse 3.0 ejecuta los plug-ins binarios de la versión 2.1. Eclipse 3.0 incluye un mecanismo de compatibilidad de entorno de ejecución binario que asegura que los binarios de plug-in 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 plug-in 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 plug-in 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 plug-ins 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 plug-in 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 plug-in 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 plug-ins 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 escuchas voten "no importa". En los releases anteriores a 3.0, los escuchas solo 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 escuchas también pueden votar "no importa" para cualquiera de estas notificaciones. Esto permite que los clientes solo 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 escucha vota "suspender" o todos los escuchas votan "no importa"; y no se suspenderá si al menos un escucha vota "no suspender" y ningún escucha vota "suspender". De forma similar, para las notificaciones de "punto de interrupción al instalar", el punto de interrupción se instalará si cualquier escucha vota instalar, o si todos los escuchas votan "no importa"; y no se instalará si al menos un escucha vota "no instalar" y ningún escucha 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 escucha 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 escucha 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 escucha 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 escucha 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 espacio 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 espacio 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 espacio 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 escuchas de construcción automática será distinto del de los escuchas posteriores al cambio. Los escuchas de construcción recibirán la notificación de todos los cambios desde el fin de la última operación de construcción. Los escuchas 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 escuchas 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
escuchas.PRE_AUTO_BUILD
reciben una notificación de
todos los cambios de recursos excepto los cambios efectuados por los
constructores y los escuchas de cambios de recursos.POST_AUTO_BUILD
reciben una notificación de
todos los cambios de recursos excepto los cambios efectuados por otros
escuchas POST_AUTO_BUILD
.No obstante, hay algunas diferencias importantes respecto a este enfoque. Antes de
Eclipse 3.0, se llamaba siempre a los escuchas de construcción automática
antes que a los escuchas POST_CHANGE
. Por esta razón, el delta recibido por los escuchas de construcción
automática era siempre un subconjunto del delta recibido por los escuchas
POST_CHANGE
.
Esta relación, esencialmente, se ha invertido. Los escuchas de construcción
automática recibirán un delta que es un superconjunto de todos los deltas
proporcionados por los escuchas POST_CHANGE
desde el fin de la
última construcción en segundo plano. Como antes, se permitirá a los escuchas de construcción automática que
modifiquen el espacio de trabajo, mientras que los escuchas posteriores al
cambio no podrán hacerlo.
Ya no será válido que, al completarse una operación de cambio de espacio de
trabajo, los escuchas de eventos AUTO_BUILD
recibirán una
notificación.
Es poco probable que este cambio afecte al código cliente que
registra los escuchas de cambios de recursos con
IWorkspace.addResourceChangeListener(IResourceChangeListener)
,
porque los eventos AUTO_BUILD
no se notificaron nunca a estos
escuchas. 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 escuchas de construcción automática o en qué hebra
se ejecutarán. Por ejemplo, si un escucha de construcción automática actualiza un modelo de
dominio para reflejar cambios en el espacio de trabajo, es posible que esta
actualización no se haya producido al devolverse la operación de cambio de espacio
de trabajo. Vale la pena indicar que solo 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 escuchas de cambios de recursos. El arreglo sugerido para esta interrupción consiste en utilizar
POST_CHANGE
en lugar de escuchas 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
espacio de trabajo simultáneamente. Cuando una hebra termina de modificar el espacio 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 plug-ins 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 rol.
En vez de registrar el manejador mediante un punto de extensión, ahora los plug-ins 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 plug-ins que suministran paquetes proporcionados, que también son suministrados por otros plug-ins. Un número muy limitado de plug-ins 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 plug-in en el caso de los plug-ins tradicionales y se especifica directamente en el caso de los plug-ins 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 plug-in Xerces verá su propia copia de estas clases, mientras que el plug-in Xalan verá la copia de las mismas. Dado que estos plug-ins, tienen que comunicarse, se producen ClassCastExceptions. Si utiliza el segundo enfoque, solo uno de los plug-ins contribuye a las clases duplicadas y ambos plug-ins 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 plug-ins 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 plug-in 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 solo 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 plug-in utilice el dominio de protección.
Elementos afectados: los plug-ins 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 plug-ins 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 plug-ins y el registro de plug-ins. 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-ins 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 plug-in 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 plug-ins 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 plug-ins actuales no son válidas.
Acción necesaria: los escritores de plug-ins 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 plug-in
(por ejemplo, Bundle.getEntry(String)
).
Elementos afectados: el código que no es de plug-in 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 plug-in 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 plug-ins.
Descripción: en Eclipse 2.1, la línea bin.includes de un plug-in 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 plug-ins tienen previsto incluir en su plug-in 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 plug-ins que exponen una API que incluye elementos de la API de entorno de ejecución cambiada.
Descripción: varios plug-ins 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 plug-ins 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 plug-ins 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 plug-in org.eclipse.core.runtime hasta el plug-in
org.eclipse.core.runtime.compatibility (que depende del plug-in 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: plug-ins 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 plug-in 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 plug-in. En el caso de que un plug-in 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 plug-ins no podrá generar un manifest.mf correcto.
Acción necesaria: los proveedores de estos plug-ins deben adaptarse para proporcionar el archivo JAR adecuado en el propio plug-in, o bien diseñar/mantener un archivo META-INF/MANIFEST.MF para su plug-in. 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
plug-ins 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 plug-in
org.eclipse.core.runtime
de la manera siguiente:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
El plug-in 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 solo están ahí por razones de compatibilidad se encuentran
en un plug-in de compatibilidad (org.eclipse.core.runtime.compatibility
).
La mayor parte del nuevo código de entorno de ejecución se halla contenido en
una colección de plug-ins
(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 solo 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 plug-in 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
plug-in 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 scripts de construcción de plug-ins. 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 utilizan 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 plug-ins. 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 utilizan 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 solo 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 plug-in 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.