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 de los conectores (y de los 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 incluían ninguna de estas líneas <?eclipse ...?>; a partir de la versión 3.0, deben incluir siempre una. Este cambio está destinado a permitir que entorno de ejecución de Eclipse reconozca los conectores anteriores a la versión 3.0 que no se hayan portado a 3.0, a fin de que pueda suministrar automáticamente una mayor compatibilidad para tales conectores. Este es el formato genérico 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 automáticamente por PDE 3.0 tienen este formato. Es muy aconsejable utilizar la herramienta de migración de conectores del PDE. Ésta inserta automáticamente la línea indicada en el manifiesto de los conectores y fragmentos de conector 2.1 y soluciona muchos de los demás cambios descritos aquí.
Si añade esta directiva a un archivo plugin.xml (manualmente o mediante 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 estaban implícitas. En 3.0, org.eclipse.core.boot ya no es necesario y los desarrolladores deben elegir org.eclipse.core.runtime o org.eclipse.core.runtime.compatibility (o ninguno de ellos), según convenga.
Nota: esta es una de las incompatibilidades que no afecta a la ejecución de los conectores binarios 2.1 en Eclipse 3.0.
El conector org.eclipse.ui, utilizado como conector principal de UI de la plataforma, suministra ahora sólo la API y los puntos de extensión para el entorno de trabajo genérico (es decir, no específico del IDE). La API y los puntos de extensión específicos del IDE y opcionales se han transferido a otros conectores.
El impacto de este cambio tiene dos vertientes: (1) los puntos de extensión org.eclipse.ui transferidos tienen ID de punto de extensión nuevos; y (2) la lista de conectores necesarios ha cambiado.
Los puntos de extensión org.eclipse.ui de la tabla siguiente se han transferido a otros conectores, provocando el cambio de sus ID de punto de extensión. Si un conector existente añade una extensión a los puntos de extensión transferidos, la referencia del atributo "point" del elemento <extension> del archivo de manifiesto del conector debe cambiarse para que haga referencia a los ID de punto de extensión nuevos correspondientes. La herramienta de migración de conectores del PDE realiza estos arreglos.
Nota: esta es una de las incompatibilidades que no afecta a la ejecución de los conectores binarios 2.1 en Eclipse 3.0. El entorno de ejecución de Eclipse 3.0 detecta automáticamente los conectores anteriores a la versión 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> mencionada anteriormente en el manifiesto del conector) y compensa automáticamente estos cambios de dependencia de punto de extensión y 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 de API suministrados anteriormente por el conector org.eclipse.ui que se han transferido a otros conectores. (Los nombres de los paquetes de API, clases, campos y métodos no han cambiado). En algunos casos, los paquetes de API están ahora distribuidos por más de un conector. Dado que las clases de API visibles para cualquier conector determinado quedan determinadas por la lista de conectores necesarios del conector, estos cambios pueden requerir el ajuste de elementos "<requires>" de un manifiesto de conector existente para obtener de nuevo acceso a la clase de API.
Este cambio sólo afecta a los conectores que dependen del conector org.eclipse.ui (es decir, que incluyen <import plugin="org.eclipse.ui"/> en la sección <requires> del manifiesto de conector); ninguno de los demás conectores resulta afectado. Si resulta afectado, es posible que sea necesario cambiar el elemento <import> o añadir elementos <import> para que todas las clases de API que el conector necesita estén en el ámbito. Es muy aconsejable que los conectores indiquen dependencias sólo de los conectores que utilicen realmente. La inclusión de dependencias innecesarias reduce el rendimiento de la ejecución, ya que el cargador de clases Java debe buscar las clases en todas las dependencias. (La herramienta de migración de conectores del PDE arreglará las dependencias y ayudará a determinar un conjunto mínimo).
Paquete de API |
Conector 2.1 |
Conector(es) 3.0 correspondientes |
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 la plataforma Eclipse 3.0 se basa en OSGi, y por tanto necesita 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.
El nuevo conector org.eclipse.core.runtime.compatibility suministra un puente de implementación entre las API antiguas y nuevas y es el nuevo directorio inicial para muchas de las API obsoletas que se encontraban anteriormente en org.eclipse.core.runtime y org.eclipse.core.boot. Los puntos de extensión del entorno de ejecución de la plataforma no resultan afectados por la reestructuración.
Al migrar el conector existente a 3.0, debe actualizarse el manifiesto del conector para que refleje la estructura nueva de los conectores de entorno de ejecución de la plataforma Eclipse. La herramienta de migración de manifiestos de conector del PDE añadirá una dependencia a org.eclipse.core.runtime.compatibility, si es necesario.
Tenga en cuenta también que, si marca el conector como 3.0 (mediante <?eclipse version="3.0"?>) y el conector define una clase Plugin, deberá importar explícitamente el conector (<import plugin="org.eclipse.core.runtime.compatibility"/>) en el manifiesto del conector o asegurarse de que la clase Plugin define el constructor por omisión.
Nota: esta es una de las incompatibilidades que no afecta a la ejecución de los conectores binarios 2.1 en Eclipse 3.0. El entorno de ejecución de Eclipse 3.0 detecta automáticamente los conectores anteriores a la versión 3.0 (por la ausencia de la línea <?eclipse version="3.0"?> en el manifiesto del conector) y compensa automáticamente estos cambios del entorno de ejecución de la plataforma.
El conector org.eclipse.xerces ya no es necesario y se ha suprimido. Se ha incorporado soporte de análisis XML a J2SE 1.4, y la presencia del conector Xerces crea conflictos de cargador de clases. Los paquetes de API javax.xml.parsers, org.w3c.dom.* y org.xml.sax.* API suministrados anteriormente por el conector org.eclipse.xerces están ahora disponibles en las bibliotecas de J2SE.
Si su conector requiere el conector org.eclipse.xerces, debe cambiar el manifiesto del conector para eliminar esta dependencia. Una vez realizada esta operación, el código del conector debe compilarse y ejecutarse sin más cambios.
Un conector binario 2.1 con una dependencia del conector org.eclipse.xerces perderá un prerrequisito cuando se ejecute en una configuración Eclipse 3.0 estándar. Como consecuencia, el conector no se activará.
Antes de Eclipse 3.0, Eclipse operaba principalmente en una sola hebra. La mayoría de los métodos de API y puntos de extensión operaban en la hebra de la UI o en una hebra originada desde un diálogo de progreso que bloqueaba la hebra de la UI. La mayoría de escritores de conectores no tenían que preocuparse demasiado de la seguridad de las hebras, aparte de asegurarse de que toda la actividad de la UI se producía en la hebra de la UI. En Eclipse 3.0 existe generalmente mucha más simultaneidad. Ahora pueden producirse muchas operaciones en una hebra de segundo plano, donde pueden ejecutarse simultáneamente a otras hebras, incluida la hebra de la UI. Todos los conectores cuyo código se ejecuta en una hebra de segundo plano deben ahora tener conocimiento de la seguridad de hebras de su código.
Además de los conectores que ejecutan explícitamente operaciones en segundo plano mediante la API org.eclipse.core.runtime.jobs
, existen varios recursos de API de plataforma y puntos de extensión que utilizan las hebras de segundo plano. Los conectores que se enganchan a estos recursos deben asegurarse de que su código está protegido en ejecución multihebra. La tabla siguiente resume la API y los puntos de extensión que ejecutan su código o parte de él en una hebra en segundo plano en Eclipse 3.0:
Punto de extensión o clase de 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 de extensión) | 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 de extensión) | Nuevo en Eclipse 3.0, se ejecuta en segundo plano |
org.eclipse.ui.decorators (punto de extensión) | Ya en segundo plano en Eclipse 2.1 |
org.eclipse.ui.startup (punto de extensión) | Ya en segundo plano en Eclipse 2.1 |
org.eclipse.team.core.org.eclipse.team.core.repository (punto de extensión) | Muchas operaciones ahora en segundo plano |
org.eclipse.team.ui.synchronizeParticipants (punto de extensión) | Nuevo en Eclipse 3.0, se ejecuta en segundo plano |
org.eclipse.debug.core.launchConfigurationTypes (punto de extensión) | Ahora se ejecuta 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 |
Existen varias estrategias disponibles para que el código sea seguro en ejecución multihebra. Una solución sencilla consiste en asegurarse de que todo el trabajo se realiza en la hebra de la UI, garantizando con ello la ejecución serializada. Este es un método habitual para los conectores de UI que no realizan trabajo intensivo de CPU. Al
realizar esta operación, tenga en cuenta el riesgo de puntos muertos inherente a
Display.syncExec
. Generalmente, Display.asyncExec
es más seguro, ya
que no presenta riesgo de puntos muertos, aunque a expensas de perder el control sobre cuándo
se ejecuta el código.
Otras técnicas para que el código sea seguro en ejecución multihebra incluyen:
org.eclipse.core.runtime.jobs.ILock
.
La ventaja de ILock
sobre los bloqueos genéricos consiste en que se
transfieren automáticamente a la hebra de la UI al realizar una operación
syncExec
, y existe soporte de detección de puntos muertos incorporado a su implementación que anota y, a continuación, resuelve los puntos muertos. Display.asyncExec
), que se procesa por completo en la hebra de la UI. java.lang.String
y org.eclipse.core.runtime.IPath
. La ventaja de los objetos inmutables consiste en el acceso de lectura extremadamente rápido, a expensas de la realización de trabajo adicional durante la modificación. Los métodos siguientes se han suprimido de la interfaz org.eclipse.ui.IWorkbenchPage. IWorkbenchPage se declara en el entorno de trabajo genérico, pero los métodos son inherentemente específicos de los recursos.
Los clientes de estos métodos IWorkbenchPage.openEditor deben llamar a los métodos estáticos públicos correspondientes declarados en la clase org.eclipse.ui.ide.IDE (del conector org.eclipse.ui.ide).
Los clientes de estos métodos IWorkbenchPage.openSystemEditor(IFile) deben convertir IFile en IEditorInput mediante el nuevo FileEditorInput(IFile) y, a continuación, llamar al método openEditor(IEditorInput,String). En otras palabras, deben reescribir page.openSystemEditor(file) as 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 hace FileEditorInput).
Nota: esta es una de las incompatibilidades que no afecta a la ejecución de los conectores binarios 2.1 en Eclipse 3.0. Eclipse 3.0 incluye un mecanismo de compatibilidad de entorno de ejecución binario que garantiza que los conectores binarios 2.1 existentes que utilicen alguno de los métodos openEditor y openSystemEditor suprimidos seguirán funcionando como en 2.1 a pesar de este cambio de la API. (En realidad, el fragmento org.eclipse.ui.workbench.compatibility "añade de nuevo" los métodos suprimidos).El método siguiente se ha suprimido de la interfaz org.eclipse.ui.IEditorPart. IEditorPart se declara en el entorno de trabajo genérico, pero el método es inherentemente específico de los recursos.
Los clientes que implementan este método deben en su lugar probar si el componente editor implementa o se adapta a org.eclipse.ui.ide.IGotoMarker (del conector org.eclipse.ui.ide) y, si es así, llamar a gotoMarker(IMarker). La clase del IDE contiene un método adecuado para hacerlo: IDE.gotoMarker(editor, marker);
Los clientes que implementan un editor que puede autoposicionarse en función de la información de IMarker deben implementar 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 método antiguo IEditorPart.gotoMarker(IMarker), las implementaciones de editor existentes pueden adaptarse a este cambio incluyendo simplemente IGotoMarker en la cláusula implements 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 Eclipse 3.0 estándar.
Los conectores que añaden editores externos implementan la interfaz lanzadora de editores org.eclipse.ui.IEditorLauncher. El método siguiente se ha suprimido de esta interfaz. IEditorLauncher se declara en el entorno de trabajo genérico, pero el método es inherentemente específico de los recursos.
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 Eclipse 3.0 estándar.
Los métodos siguientes se han suprimido de la interfaz org.eclipse.ui.IEditorRegistry. IEditorRegistry se declara en el entorno de trabajo genérico, pero los métodos son inherentemente específicos de los recursos.
Existen constantes nuevas que representan el editor externo del sistema e identificadores de editor in situ del sistema (SYSTEM_EXTERNAL_EDITOR_ID y SYSTEM_INPLACE_EDITOR_ID). Estos dos editores requieren una entrada de editor que 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 método siguiente se ha suprimido de la interfaz org.eclipse.ui.IWorkbench. IWorkbench se declara en el entorno de trabajo genérico, pero el método es inherentemente específico de los recursos.
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 Eclipse 3.0 estándar.
Para que org.eclipse.ui.texteditor.AbstractTextEditor se independiente de IFile, org.eclipse.ui.texteditor.AbstractDocumentProvider introduce el concepto de operación de proveedor de documentos (DocumentProviderOperation) y un ejecutor de operaciones de proveedor de documentos (IRunnableContext). Cuando se le solicita realizar operaciones de restablecimiento, guardado o sincronización, AbstractDocumentProvider crea operaciones de proveedor de documentos y utiliza el ejecutor de operaciones para ejecutarlas. Las subclases pueden suministrar el contexto ejecutable por medio del método getOperationRunner. A continuación figura un resumen de los cambios a los que los clientes deben adaptarse:
La subclase org.eclipse.ui.editors.text.StorageDocumentProvider de AbstractDocumentProvider implementa el método getOperationRunner para que siempre devuelva nulo. Esto significa que las subclases de StorageDocumentProvider no deben resultar afectadas por este cambio.
La subclase org.eclipse.ui.editors.text.FileDocumentProvider de StorageDocumentProvider implementa el método getOperationRunner, que devuelve un IRunnableContext para ejecutar las operaciones de tipo DocumentProviderOperations dadas dentro de una una operación WorkspaceModifyOperation. Otros cambios realizados en FileDocumentProvider son:
Cambios realizados 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 subclass org.eclipse.ui.texteditor.StatusTextEditor de AbstractTextEditor suministra el método de predicado isErrorStatus(IStatus). Las subclases pueden alterarse temporalmente para decidir si un estado determinado debe considerarse o no un error.
Cambios realizados en org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:
Como parte del soporte de introducción 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 por medio de las opciones de menú Ventana > Mostrar vista > Básica > Consola, y la utilizan la integración Ant y la depuración de Eclipse.
El ID de vista de la consola ha cambiado de org.eclipse.debug.ui.ConsoleView a org.eclipse.ui.console.ConsoleView. Los conectores 2.1 que abran programáticamente la consola no podrán hacerlo, ya que la perteneciente a la vista antigua ha dejado de existir.
En la versión 3.0, los tipos de retorno de los métodos org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) e installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) han cambiado de boolean a int para que los escuchadores puedan votar "don't care" (no importa). En releases anteriores a 3.0, los escuchadores sólo podían votar "suspend" (suspender) o "don't suspend" (no suspender) cuando se alcanzaba un punto de interrupción, e "install" (instalar) o "don't install" (no instalar) cuando estaba a punto de instalarse un punto de interrupción. En el release 3.0, los escuchadores también pueden votar "don't care" para cualquiera de estas notificaciones. Esto permite a los clientes emitir un voto decisivo sólo en situaciones importantes. Para notificaciones de "encuentro de punto de interrupción", el punto de interrupción quedará suspendido si alguno de los escuchadores vota "suspend", o todos los escuchadores votan "don't care"; y no quedará suspendido si como mínimo un escuchador vota "don't suspend" y ningún escuchador vota "suspend". De modo parecido, para notificaciones de "instalación de punto de interrupción", el punto de interrupción se instalará si alguno de los escuchadores vota instalar, o todos los escuchadores votan "don't care"; y no se instalará si como mínimo un escuchador vota "don't install" y ningún escuchador vota "install". En general, los implementadores deben devolver DONT_CARE a menos que tengan una opinión convincente en uno u otro sentido. Es importante tener en cuenta, por ejemplo, que el hecho de votar "suspend" alterará temporalmente el voto "don't suspend" emitido por los demás escuchadores.
Los clientes que crean puntos de interrupción en código Java o reaccionan a ellos deben implementar la interfaz IJavaBreakpointListener. Probablemente existan pocos clientes más allá de las propias JDT, guarde el que ha notificado el problema (error 37760) solucionado por este cambio. Este es un cambio rupturista con respecto al código existente que implementa la interfaz IJavaBreakpointListener. Este código debe modificarse para que devuelva un valor de tipo int adecuado antes de compilarlo o ejecutarlo en el release 3.0.
Antes del release 3.0, los métodos de la clase SWT org.eclipse.swt.dnd.Clipboard estaba tácitamente permitido que se ejecutaran en hebras que no fueran la de la UI. Esta negligencia provocaba anomalías en GTK, donde el sistema operativo requiere que todas las interacciones del portapapeles se realicen en la hebra de la UI. La negligencia no se había revelado anteriormente debido a que muchas aplicaciones son de una sola hebra y reciben la mayoría de sus pruebas en Windows. Para que la API de portapapeles sea sostenible y portable en diversas plataformas, en el release 3.0 la especificación e implementación de todos los métodos de API de portapapeles han cambiado para lanzar una excepción SWT (ERROR_THREAD_INVALID_ACCESS) si se invocan desde una hebra que no sea la de la UI. Los componentes de Eclipse como el editor de texto suministran habitualmente y de forma automática los servicios de portapapeles, lo cual aísla muchos clientes de este cambio rupturista. El código existente que utiliza directamente el portapapeles debe asegurarse de llamar a los métodos de la API en la hebra correcta, mediante Display.asyncExec o syncExec cuando proceda para desplazar los accesos a la hebra de la UI.
En el release 3.0, SWT notifica los eventos de pulsación de teclas antes de realizar el trabajo en el SO. Este proceso se efectúa mucho antes que en los releases anteriores a 3.0. Este cambio se ha realizado para dar soporte a los enlaces de teclas de Eclipse, que necesitan interceptar los eventos de tecla antes de que ningún widget tenga la oportunidad de procesar el carácter. Las consecuencias de este cambio son visibles en el código que maneja directamente los eventos org.eclipse.swt.SWT.KeyDown de bajo nivel. Por ejemplo, significa que cuando un escuchador de un widget de texto recibe un evento de pulsación de teclas, el contenido del widget (getText()) aún no incluirá la tecla que se acaba de pulsar (como hubiera sucedido antes del release 3.0). La forma recomendada de obtener el texto completo del widget, incluida la tecla actual, es manejar los eventos SWT.Modify o SWT.Verify de alto nivel en lugar del eventos SWT.KeyDown de bajo nivel; el código que lo ejecuta de hecho de esta forma no resulta afectado por este cambio.
Antes del release 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 teclear Control+tabulador, Mayús+tabulador o Control+AvPág se activaba automáticamente el cruce al widget siguiente/anterior sin notificar un evento de tecla. Este comportamiento no estaba especificado y va contra la norma que indica que los lienzos visualizan cada una de las teclas pulsadas en ellos. La forma adecuada de manejar el cruce es registrando un escuchador de cruces. Para dar soporte correctamente a los enlaces de teclas en Eclipse 3.0, el comportamiento por omisión se ha cambiado de forma que ahora el lienzo visualiza eventos de teclas Control+tabulador, Mayús+tabulador, Control+RePág y Control+AvPág en lugar del cruce. Si utiliza un lienzo original o define una subclase de lienzo, asegúrese de registrar un escuchador de cruces.
Las selecciones de ratón de los elementos de las clases SWT org.eclipse.swt.widgets.Table y Tree generan la secuencia de eventos MouseDown-Selection-MouseUp uniformemente en todos los entornos operativos. De forma parecida, la selecciones de teclado generan la secuencia de eventos KeyDown-Selection-KeyUp uniformemente en todos los entornos operativos. Antes del release 3.0, el orden de los eventos no era uniforme, y Motif y Photon variaban con respecto al resto notificando siempre en primer lugar el evento Selection; es decir, Selection-MouseDown-MouseUp o Selection-KeyDown-KeyUp. En 3.0, el orden de los eventos en Motif y Photon ha cambiado para que coincida con los demás. No es probable que el código existente funcionalmente correcto en {Windows, GTK} y en {Motif, Photon} resulte afectado. Sin embargo, es aconsejable comprobar el código para asegurarse de que no se basa en un orden de eventos no válido.
org.eclipse.core.runtime.IStatus
contiene una constante de gravedad nueva,
IStatus.CANCEL
, que puede utilizarse para indicar la cancelación. Los llamadores de IStatus.getSeverity()
que se basan en la limitación del conjunto de gravedades posibles a IStatus.OK
,
INFO
, WARNING
y ERROR
resultan afectados por esta adición. Los llamadores de getSeverity
deben actualizar su código para que incluya la gravedad nueva.
En Eclipse 3.0, las construcciones automáticas del área de trabajo se producen en una hebra de segundo plano. Esto ha exigido el cambio del contrato de API a
org.eclipse.core.resources.IResourceChangeEvent
. El contrato de
IResourceChangeEvent
garantizaba anteriormente el siguiente orden de eventos para todos los cambios del área de trabajo:
PRE_DELETE
o PRE_CLOSE
si era aplicablePRE_AUTO_BUILD
POST_AUTO_BUILD
POST_CHANGE
Con la construcción automática ejecutada ahora en segundo plano, ya no existe ninguna garantía relativa a 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 han eliminado de la operación. La estructura resultante es parecida a la siguiente:
PRE_DELETE
o PRE_CLOSE
si era aplicablePOST_CHANGE
Periódicamente, la plataforma realizará una operación de construcción del área de trabajo en segundo plano. Tenga en cuenta que esto se producirá independientemente de que la construcción automática esté activada o desactivada. No se especificará el momento exacto de esta construcción. La estructura de la operación de construcción será parecida a la siguiente:
PRE_BUILD
(PRE_BUILD
es el nombre nuevo de PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
es el nombre nuevo de POST_AUTO_BUILD)
POST_CHANGE
POST_CHANGE
reciben la notificación de absolutamente todos los cambios producidos durante el tiempo en que se registran. Esto incluye los cambios efectuados por los constructores y los cambios efectuados por otros escuchadores.PRE_AUTO_BUILD
reciben la notificación de todos los cambios de recurso excepto de los cambios efectuados por constructores y escuchadores de cambios de recurso. POST_AUTO_BUILD
reciben la notificación de todos los cambios de recurso excepto de los cambios efectuados por otros escuchadores POST_AUTO_BUILD
. 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
.
Ahora, básicamente esta relación se ha invertido. Los escuchadores de construcción automática recibirán un delta que es un superconjunto de todos los deltas suministrados a los escuchadores POST_CHANGE
desde el final de la última construcción en segundo plano. Como antes, los escuchadores de construcción automática podrán modificar el área de trabajo, y no así los escuchadores postcambio.
Ya no se cumplirá la norma según la cual, al finalizar una operación de cambio del área de trabajo, se notifican dichos escuchadores de eventos AUTO_BUILD
.
No es probable que el código de cliente que registra los escuchadores de cambios de recurso en
IWorkspace.addResourceChangeListener(IResourceChangeListener)
resulte afectado por este cambio, ya que los eventos AUTO_BUILD
nunca se han notificado a estos escuchadores. Sin embargo, es probable que los clientes que utilicen
IWorkspace.addResourceChangeListener(IResourceChangeListener,int)
y especifiquen una máscara de eventos que incluya eventos AUTO_BUILD
resulten afectados por este cambio si hacen suposiciones acerca de cuándo se ejecutan los escuchadores de construcción automática o en qué hebra se ejecutan. Por ejemplo, si un escuchador de construcción automática actualiza un modelo de dominio para reflejar los cambios realizados en el área de trabajo, puede que dicha actualización no se hay producido cuando la operación de cambio del área de trabajo efectúe el retorno. El hecho de que sólo el código a nivel de UI pueda resultar afectado de este modo no significa nada. El código a nivel del
núcleo al que se llama por medio de API puede llamarse dentro del ámbito de
IWorkspaceRunnable
, y por tanto nunca puede estar seguro de cuándo se llamará a los escuchadores de cambios de recurso. El arreglo sugerido para esta ruptura consiste en utilizar POST_CHANGE
en lugar de escuchadores de construcción si es necesario para que la notificación se produzca antes de que finalice la operación.
Ya no estará garantizado que todos los cambios de recurso ocurridos durante el ámbito dinámico de IWorkspaceRunnable
se agrupen por lotes en una sola notificación. Este mecanismo aún puede utilizarse para agrupar los cambios a fin de evitar construcciones y notificaciones innecesarias, pero la plataforma puede decidir ahora realizar notificaciones durante la operación. No es probable que este cambio del contrato de API represente una ruptura para los clientes existentes. Es equivalente al proceso en el que la plataforma decide llamar a IWorkspace.checkpoint
periódicamente durante operaciones de larga ejecución. 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 aún no se haya completado. Este cambio también permite a los usuarios empezar a trabajar en un conjunto de recursos antes de que finalice la operación. Por ejemplo, ahora el usuario puede empezar a examinar archivos en un proyecto que sigue en proceso de reserva. El
nuevo método IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int,
IProgressMonitor)
contiene un distintivo opcional, AVOID_UPDATE
, que las operaciones pueden utilizar como sugerencia a la plataforma para especificar si se desean 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
ha cambiado para utilizar el servicio de manejador de corriente de URL suministrado por OSGi. El soporte de OSGi es superior al de Eclipse 2.1 y maneja correctamente los manejadores dinámicos. Debido a diversos problemas de diseño del mecanismo de manejadores de URL Java básicos, los URLStreamHandlers registrados con el servicio de manejador de OSGi deben implementar org.osgi.service.url.URLStreamHandlerService
.
Acción necesaria: Anteriormente, la clase de manejador 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 que implemente la interfaz org.osgi.service.url.URLStreamHandlerService
. La
infraestructura de OSGi suministra una clase base abstracta
(org.osgi.service.url.AbstractURLStreamHandlerService
) de la que pueden crearse subclases de forma trivial para cumplir este cometido.
En lugar de registrar el manejador mediante un punto de extensión, ahora los conectores deben hacerlo registrando su manejador como 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 suministrados también por otros conectores. Un número muy limitado de conectores resulta afectado por este cambio y algunos de ellos se beneficiarán en realidad del mismo (consulte la información que figura más adelante).
Descripción: en Eclipse 2.x, los cargadores de clases buscaban las clases en el siguiente orden: consultar (1) cargador de clases padre (en la práctica, se trataba del cargador de clases de arranque Java), a continuación (2) su propio contenido de vía de acceso de clases y finalmente (3) todos sus prerrequisitos en el orden declarado. OSGi ofrece una optimización de este modelo. Según la misma, un cargador de clases consultará (1) el cargador de clases padre (de nuevo, se trata en realidad del cargador de clases de arranque Java), a continuación (2a) un solo prerrequisito conocido para añadir clases al paquete consultado o (2b) sus propias entradas de vía de acceso de clases correspondientes a la clase deseada.
El cargador de clases determina si debe consultarse a sí mismo o a sus prerrequisitos en función de sus paquetes importados y requeridos. Esta información se deduce del contenido del conector en el caso de los conectores tradicionales, y se especifica directamente en el caso de los conectores con manifiesto de paquete compuesto OSGi explícito. En cualquier caso, se sabe a priori qué cargadores de clases suministrarán las clases de qué paquetes. Esto ofrece mejoras de rendimiento y una solución al molesto problema de que varios prerrequisitos añadan las mismas clases.
Tomemos por ejemplo el caso de Xerces y Xalan, que contienen ambos diversas clases procedentes de paquetes org.xml. mediante el primer método, el conector Xerces vería su copia de estas clases mientras el conector Xalan vería la copia de las mismas. Dado que estos conectores necesitan comunicarse, se producen excepciones de tipo ClassCastExceptions. Mediante el segundo método, sólo uno de los conectores añade las clases duplicadas y ambos conectores ven las mismas copias.
Acción necesaria: La acción necesaria depende de las particularidades del caso. Los desarrolladores afectados deben revisar su vía de acceso de clases y resolver los conflictos que puedan producirse.
Elementos afectados: los conectores que esperan que el dominio de protección de su cargador de clases se establezca siempre.
Descripción: En Eclipse 2.1, los cargadores de clases de conector eran java.security.SecureClassloaders y, por tanto, siempre tenían establecido el dominio de protección. En Eclipse 3.0, los cargadores de clases no amplían SecureClassloader y sólo establecen el dominio de protección si la seguridad Java está activada (que no es el caso habitual).
Acción necesaria: la acción necesaria dependerá del escenario en el que el conector utilice el dominio de protección.
Elementos afectados: los conectores que convierten temporalmente objetos de 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 se especifica en La API de Eclipse 2.1, se indica explícitamente este cambio por que se han encontrado instancias de conectores que se basan en esta relación en la implementación de 2.1.
Descripción: la API de Eclipse proporciona una serie de interfaces (por ejemplo,
IPluginDescriptor
) y las así llamadas clases de "modelo" (por ejemplo,
PluginDescriptorModel
) relacionadas con los conectores y el el registro de conectores. En la implementación de Eclipse 2.1, las clases de modelo implementan las interfaces relevantes. En el nuevo entorno de ejecución basado en OSGi, el registro de conectores se han rediseñado significativamente para permitir una separación entre la carga de clases y los aspectos relativos a los prerrequisitos de los conectores, por un lado, y los aspectos relativos a extensiones y puntos de extensión por otro. Por tanto, el entorno de ejecución de Eclipse 3.0 no es capaz de mantener la relación de la implementación presente en el release 2.1.
Acción necesaria: los conectores basados en esta relación no de API deben rediseñar el código de acuerdo con su caso. En la sección de cambios recomendados de este documento y en el Javadoc de las clases y método relacionados figura más información acerca de este tema.
Elementos afectados: los conectores que utilizan
org.eclipse.core.runtime.ILibrary
.
Descripción: el nuevo entorno de ejecución conserva las entradas de vía de acceso de clases de forma diferente e incompatible con Eclipse. En consecuencia, la capa de compatibilidad no puede modelar correctamente las estructuras OSGi subyacentes como objetos ILibrary. El soporte de compatibilidad del entorno de ejecución crear objetos ILibrary, pero debe asumir valores por omisión para todo excepto para la vía de acceso de la biblioteca.
Acción necesaria: los usuarios de ILibrary deben considerar la posibilidad de acceder a los valores de cabecera deseados (por ejemplo, Bundle-Classpath
) desde el paquete compuesto (Bundle) adecuado (consulte Bundle.getHeaders()
) y utilizar la clase de ayuda ManifestElement
para interpretar las entradas. Consulte el javadoc de clases para obtener más detalles.
Elementos afectados: los conectores que efectúan suposiciones relativas a su estructura de instalación, ubicación y diseño del sistema de archivos local.
Descripción: los métodos como IPluginDescriptor.getInstallURL()
devuelven URL con un formato determinado. A pesar de que no se especifica su formato, diversos conectores hacen suposiciones basadas en la implementación actual. Por ejemplo,
pueden esperar obtener un URL file:
y utilizar URL.getFile() y la manipulación de java.io.File
en el resultado. Hasta la fecha, este sistema ha funcionado pero es bastante frágil. Por ejemplo, si un conector se instala en un servidor Web, es posible que se devuelva un URL de tipo http:
. El nuevo entorno de ejecución de Eclipse 3.0 es aún más flexible y abre más posibilidades para configuraciones de ejecución (por ejemplo, mantenimiento de conectores completos en archivos JAR en lugar de explotarlos en directorios).
Es decir, aunque el nuevo entorno de ejecución basado en OSGi no representa realmente una ruptura con la API de 2.1, expone más casos en los que las suposiciones efectuadas en los conectores actuales no son válidas.
Acción necesaria: los escritores de conectores deben asegurarse de que la
información a la que necesitan acceso está disponible por medio de getResource()
(y se encuentra en la vía de acceso de clases) o utilizar la API relevante para acceder al contenido de un conector (por ejemplo, Bundle.getEntry(String)
).
Elementos afectados: el código que no es de conector y llama a determinados métodos de la clase org.eclipse.core.boot.BootLoader
.
Descripción: los métodos estáticos BootLoader.startup(), shutdown() y run() se han transferido a org.eclipse.core.runtime.adaptor.EclipseStarter, que forma parte de la infraestructura de OSGi. Esta API es la interfaz entre el método main() de startup.jar y la infraestructura de OSGi/entorno de ejecución de Eclipse. La reestructuración del entorno de ejecución no ha permitido conservar estos métodos en BootLoader. La clase BootLoader antigua se encuentra ahora en la capa de compatibilidad del entorno de trabajo y ha quedado obsoleta, y los métodos transferidos no realizan ninguna acción.
No existe sustitución para el método BootLoader.getRunnable() antiguo, puesto que el entorno de ejecución no tiene ya soporte para la adquisición de aplicaciones individuales. En lugar de ello, los usuarios deben indicar la aplicación en cuestión al iniciar la plataforma.
Acción necesaria: en general, pocos usuarios utilizan esta API (no puede utilizarse desde dentro de un conector Eclipse). En el caso raro en que así sea, debe adaptarse el código para que utilice los métodos correspondientes de EclipseStarter.
Elementos afectados: todos los conectores.
Descripción: en Eclipse 2.1, una línea bin.includes del archivo build.properties del conector no tenía que contener la lista de archivos JAR de su declaración de biblioteca en el archivo plugin.xml; estos JAR se añadían libremente. En Eclipse 3.0, la lista de archivos de la sección bin.includes del archivo build.properties es una lista exhaustiva y debe incluir todos los archivos que los desarrolladores de conectores tengan previsto incluir en su conector al construir o exportar.
Acción necesaria: asegúrese de que la línea bin.includes del archivo build.properties incluye 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: diversos conectores exponen una API que incluye elementos de la API de entorno de ejecución. Con los cambios realizados en el entorno de ejecución de Eclipse 3.0 indicados aquí, los conectores cliente deben reevaluar su utilización de la API de entorno de ejecución en su API.
Acción necesaria: este escenario es bastante insólito, ya que ha cambiado muy poco de la API de entorno de ejecución de Eclipse. Dependiendo del escenario, puede que los clientes deban 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 eliminado. La API asociada con el argumento Factory se ha transferido del conector org.eclipse.core.runtime al conector
org.eclipse.core.runtime.compatibility (que depende del conector de entorno de ejecución). En consecuencia, también se ha transferido el método de análisis.
Acción necesaria: los usuarios de este método deben utilizar el mismo método de la clase org.eclipse.core.runtime.model.PluginRegistryModel
.
Elementos afectados: los conectores que especifican código en su vía de acceso de clases, pero no suministran ese código (es decir, es un fragmento el que suministra el JAR; por ejemplo el conector org.eclipse.swt).
Descripción: el nuevo entorno de ejecución debe convertir internamente los archivos plug.xml en archivos manifest.mf. Esta operación se realiza mediante una transformación mecánica directa y un análisis de los JAR listados y suministrados por el conector. En caso de que un conector especifique un JAR en su vía de acceso de clases pero no lo suministre, no existirá código que analizar y el conversor del conector no podrá generar un archivo manifest.mf correcto.
Acción necesaria: los proveedores de tales conectores deben efectuar cambios para suministrar el JAR adecuado en el propio conector o fabricar/mantener un archivo META-INF/MANIFEST.MF para su conector. Generalmente, esto puede realizarse utilizando el PDE para obtener el manifiesto inicial y, a continuación, añadiendo la cabecera Provide-Package adecuada.
Elementos afectados: Los scripts (por ejemplo, archivos build.xml de Ant) 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 diversos conectores y archivos JAR nuevos. Su introducción era obligada por la reestructuración del entorno de trabajo en componentes configurables. En la mayoría de situaciones del entorno de ejecución, estos cambios son transparentes.
Sin embargo, si tiene scripts build.xml (o similares) personalizados que actualmente compilan código en org.eclipse.core.runtime
, deberá actualizarlos para que funcionen correctamente. Un script típico contiene una entrada de vía de acceso de clases en una tarea
<javac> que hace referencia al conector org.eclipse.core.runtime
de la forma siguiente:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
El conector de entorno de ejecución sigue conteniendo gran parte del código de entorno de ejecución original.
Sin embargo, diversos componentes del entorno de ejecución que sólo están allí por razones de compatibilidad se encuentran en un conector de compatibilidad (org.eclispe.core.runtime.compatibility
).
La mayor parte del código del nuevo entorno de ejecución se encuentra en una colección de conectores (org.eclipse.osgi.*
).
Acción necesaria: los desarrolladores deben añadir las entradas que figuran más abajo según convenga para eliminar los errores de compilación. Aunque a continuación figura la lista completa del conjunto de archivos JAR suministrados, las utilizaciones típicas requieren sólo un subconjunto en la vía de acceso de clases durante la compilación. Como de costumbre, la inclusión de los directorios /bin es discrecional. Las entradas figuran en agrupaciones lógicas según el conector que las suministra:
Además, pueden ser necesarios los siguientes JAR en casos especiales:
Al actualizar tales scripts, también debe tener la oportunidad de borrar (es decir, eliminar) las referencias a org.eclipse.core.boot
. Este conector está obsoleto y ya no contiene código. Las entradas pueden dejarse en la vía de acceso de clases, pero no tienen ninguna finalidad y sería conveniente eliminarlas. Debería eliminar:
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
Elementos afectados: Los scripts (por ejemplo, archivos build.xml de Ant) que utilizan la tarea eclipse.buildScript.
Descripción: la construcción de PDE ha introducido una propiedad nueva en la tarea eclipse.buildScript para controlar la generación de scripts de construcción de conectores. La introducción del nuevo entorno de ejecución basado en OSGi exigía este cambio.
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 false. Por ejemplo:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementos afectados: Los scripts (por ejemplo, archivos build.xml de Ant) que utilizan la tarea eclipse.buildScript.
Descripción: la construcción de PDE ha introducido una propiedad nueva en la tarea eclipse.buildScript para controlar la generación de scripts de construcción de conectores. La introducción del nuevo entorno de ejecución basado en OSGi exigía este cambio.
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 false. Por ejemplo:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementos afectados: Los scripts (por ejemplo, archivos build.xml de Ant) que utilizan la tarea eclipse.buildScript.
Descripción: la construcción de PDE ha cambiado el comportamiento de la tarea eclipse.fetch para facilitar la construcción de Eclipse en un estilo de construcción automatizado. Ahora, el estilo de los elementos sólo da soporte a una entrada a la vez y el scriptName se pasa siempre por alto.
Acción necesaria: si tenía una lista de entradas en el código "elements" de una llamada eclipse.fetch, distribúyalas por varias llamadas a eclipse.fetch. Si suele establecer el scriptName, tenga en cuenta que ahora el script de extracció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 se incluye. 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, para suministrar información de sello personal) deben en lugar de ello efectuar cambios en el archivo config.ini. 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 de lanzamiento era siempre splash.bmp en el directorio del conector de sello personal. En 3.0, la ubicación de la imagen de lanzamiento se suministra explícitamente en la clave osgi.splashPath del archivo config.ini.