O Eclipse mudou relativamente à incompatibilidade entre o 2.1 e o 3.0 de formas que afectam os plug-ins. As entradas seguintes descrevem as áreas que foram alteradas e facultam instruções para migrar os plug-ins 2.1 para 3.0. Repare que apenas necessita de ver aqui se está a detectar problemas na execução do plug-in 2.1 no 3.0.
O cabeçalho dos ficheiros do manifesto para plug-ins (e fragmentos de plug-in) foi alterado para incluir uma nova linha que identifique a versão de manifesto do plug-in apropriada. Antes do 3.0, os plug-ins não tinham uma destas linhas <?eclipse ...?>; depois do 3.0, têm sempre de ter uma. Esta alteração serve para permitir que o tempo de execução do Eclipse reconheça de forma fidedigna os plug-ins anteriores ao 3.0 que não tenham sido transportados para o 3.0, de forma a poder facultar automaticamente maior compatibilidade binária para esses plug-ins. Este é o formato geral do ficheiro plugin.xml (fragment.xml é semelhante):
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
...
</plugin>
Os manifestos do plug-in criados pelo PDE 3.0 têm automaticamente este formato. Recomenda-se vivamente que utilize a ferramenta de migração de plug-ins de PDE. Insere automaticamente a linha indicada no manifesto de plug-ins 2.1 e fragmentos de plug-in, enviando muitas das outras alterações aqui descritas.
Se adicionar esta directiva a um plugin.xml (manualmente ou utilizando PDE), o ficheiro também tem de ser actualizado para listar de forma explícita os plug-ins de que depende. Por exemplo, antes do Eclipse 3.0, as dependências de org.eclipse.core.runtime e de org.eclipse.core.boot eram implícitas. Com o 3.0, org.eclipse.core.boot já não é necessário e os programadores têm de optar entre org.eclipse.core.runtime ou org.eclipse.core.runtime.compatibility (ou nenhum) conforme seja apropriado.
Nota: Trata-se de uma das incompatibilidades que não tem impacto na forma como os plug-ins binários 2.1 são executados pelo Eclipse 3.0.
O plug-in org.eclipse.ui, que era o plug-in principal da IU da Plataforma, faculta agora apenas a API e os pontos de extensão para a área de trabalho genérica (ou seja, não específico de IDE). A API e os pontos de extensão opcionais e específicos de IDE foram movidos para outros plug-ins.
O impacto desta alteração tem duas consequências: (1) os pontos de extensão org.eclipse.ui movidos têm novos ids de pontos de extensão; e (2) a lista de plug-ins necessários foi alterada.
Os pontos de extensão org.eclipse.ui na tabela seguinte foram movidos para plug-ins diferentes, levando a que os ids do ponto de extensão fossem alterados. Se um plug-in existente contribuir uma extensão para os pontos de extensão movidos, a referência no atributo "point" do elemento <extension> no ficheiro de manifesto do plug-in tem de ser alterada para remeter para os novos ids de ponto de extensão correspondentes. A ferramenta de migração de plug-ins PDE realiza estas correcções.
Nota: Trata-se de uma das incompatibilidades que não tem impacto na forma como os plug-ins binários 2.1 são executados pelo Eclipse 3.0.O tempo de execução do Eclipse 3.0 detecta automaticamente os plug-ins anteriores a 3.0 (através da ausência da já mencionada linha <?eclipse version="3.0"?> no manifesto do plug-in) e compensa automaticamente estas alterações de dependência do ponto de extensão e do plug-in.
Antigo id do ponto de extensão |
Novo id do ponto de extensão |
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 |
A tabela seguinte enumera os pacotes da API anteriormente facultados pelo plug-in org.eclipse.ui, que foram movidos para plug-ins diferentes. (os nomes dos pacotes, classes, campos e métodos da API não foram alterados.) Nalguns casos, os pacotes da API estão agora divididos por mais do que um plug-in. Uma vez que as classes da API visíveis para um qualquer plug-in são determinadas pela lista desse plug-in de plug-ins necessários, estas alterações podem necessitar de ajustar elementos "<requires>" num manifesto existente do plug-in para voltar a ter acesso à classe da API.
Esta alteração apenas afecta os plug-ins que dependem do plug-in org.eclipse.ui (ou seja, inclui <import plugin="org.eclipse.ui"/> na secção <requires> do manifesto do plug-in); nenhum dos outros plug-ins é afectado. Caso algum seja afectado, poderá ter de alterar o elemento <import> ou adicionar mais elementos <import> de forma a que todas as classes da API de que o plug-in necessita estejam no âmbito. Recomendamos vivamente que os plug-ins apenas declarem dependências sobre os plug-ins que realmente utilizarem. A inclusão de dependências desnecessárias reduz o rendimento de tempo de execução porque o carregador da classe Java tem de pesquisar classes em todas as dependências. (A ferramenta de migração de plug-ins de PDE vai corrigir as dependências e ajudar a determinar um conjunto mínimo.)
Pacote da API |
Plug-in 2.1 |
Plug-ins(s) 3.0 correspondentes |
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 |
O Tempo de Execução da Plataforma do Eclipse 3.0 baseia-se em OSGi, necessitando de alterações à estrutura dos dois plug-ins de Tempo de Execução da Plataforma, org.eclipse.core.runtime e org.eclipse.core.boot.
Um novo plug-in org.eclipse.core.runtime.compatibility faculta uma ponte de implementação entre as antigas e novas APIs e é a nova localização de muitas APIs obsoletas anteriormente localizadas em org.eclipse.core.runtime e org.eclipse.core.boot. Os pontos de extensão do Tempo de Execução da Plataforma não são afectados pela reestruturação.
Ao migrar o plug-in existente para o 3.0, o manifesto do plug-in tem de ser actualizado para reflectir a nova estrutura dos plug-ins do Tempo de Execução da Plataforma Eclipse. A ferramenta de migração do manifesto do plug-in de PDE vai adicionar uma dependência de org.eclipse.core.runtime.compatibility, caso seja necessário.
Repare também que se marcar o plug-in como 3.0 (utilizando <?eclipse version="3.0"?>) e o plug-in definir uma classe de Plugin, tem de explicitamente <import plugin="org.eclipse.core.runtime.compatibility"/> no manifesto do plug-in ou assegurar que a classe do Plugin define o construtor predefinido.
Nota: Trata-se de uma das incompatibilidades que não tem impacto na forma como os plug-ins binários 2.1 são executados pelo Eclipse 3.0.O tempo de execução do Eclipse 3.0 detecta automaticamente plug-ins anteriores a 3.0 (através da ausência da linha <?eclipse version="3.0"?> no manifesto do plug-in) e compensa automaticamente estas alterações ao Tempo de Execução da Plataforma.
O plug-in org.eclipse.xerces já não é necessário e foi eliminado. O suporte de identificação de XML está incorporado no J2SE 1.4 e a presença do plug-in Xerces cria conflitos do carregador de classes. Os pacotes da API javax.xml.parsers, org.w3c.dom.* e org.xml.sax.* anteriormente facultados pelo plug-in org.eclipse.xerces estão agora disponíveis nas bibliotecas do J2SE.
Se o seu plug-in necessitar do plug-in org.eclipse.xerces, tem de alterar o manifesto do plug-in para remover esta dependência declarada. Uma vez realizada esta acção, o código do plug-in deve ser compilado e executado sem mais alterações.
Um plug-in 2.1 binário com uma dependência declarada sobre o plug-in org.eclipse.xerces não terá um pré-requisito quando for executado numa configuração padrão do Eclipse 3.0. Como consequência, o plug-in não será activado.
Antes do Eclipse 3.0, o Eclipse na maior parte das vezes funcionava num único módulo. A maior parte dos métodos e pontos de extensão da API funcionavam no módulo da IU ou num módulo gerado de uma caixa de diálogo de progresso que bloqueava o módulo da IU. A maioria dos escritores de plug-in não têm de se preocupar muito com a segurança do módulo, além de assegurar que toda a actividade da IU ocorreria no módulo da IU. No Eclipse 3.0, existem normalmente muito mais simultaneidade. Muitas operações podem ocorrer num módulo de segundo plano, onde podem ser executados simultaneamente com outros módulos, incluindo o módulo da IU. Todos os plug-ins cujo código seja executado num módulo de segundo plano agora têm de se assegurar da segurança do módulo do respectivo código.
Além dos plug-ins que estejam explicitamente a executar operações em segundo plano utilizando a API org.eclipse.core.runtime.jobs
, existem várias funcionalidades e pontos de extensão da API da plataforma que utilizam os módulos de segundo plano.
Os plug-ins que utilizem estas funcionalidades têm de se assegurar que o respectivo código tem protecção em relação a módulos.
A tabela seguinte resume a API e os pontos de extensão que executam algum ou todo o código num módulo de segundo plano no Eclipse 3.0:
Ponto de extensão ou classe de API |
Notas |
org.eclipse.core.runtime.IRegistryChangeListener | Novidade no Eclipse 3.0, executado em segundo plano |
org.eclipse.core.resources.IResourceChangeListener | Eventos AUTO_BUILD agora em segundo plano |
org.eclipse.core.resources.builders (ponto de ext.) | Construção automática agora em segundo plano |
org.eclipse.core.resources.ISaveParticipant | SNAPSHOT agora em segundo plano |
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ponto de ext.) | Novidade no Eclipse 3.0, executado em segundo plano |
org.eclipse.ui.decorators (ponto de ext.) | Já em segundo plano no Eclipse 2.1 |
org.eclipse.ui.startup (ponto de ext.) | Já em segundo plano no Eclipse 2.1 |
org.eclipse.team.core.org.eclipse.team.core.repository (ponto de ext.) | Muitas operações agora em segundo plano |
org.eclipse.team.ui.synchronizeParticipants (ponto de ext.) | Novidade no Eclipse 3.0, executado em segundo plano |
org.eclipse.debug.core.launchConfigurationTypes (ponto de ext.) | Agora executado em segundo plano |
org.eclipse.jdt.core.IElementChangedListener | ElementChangedEvent.PRE_AUTO_BUILD agora executado em segundo plano, POST_RECONCILE já era executado em segundo plano
|
Existem várias estratégias disponíveis para que o código fique com protecção em relação a módulos. Uma solução fácil é assegurar que todos o trabalho funciona no módulo da IU, logo assegurando a execução em série.
Trata-se de uma abordagem comum para plug-ins da IU que não estejam a executar um processamento intensivo na CPU. Ao fazer isto, tenha em atenção o risco de impasse inerente a Display.syncExec
. Display.asyncExec
é geralmente mais seguro, visto que não introduz um risco de impasse, tendo como consequência a perda de controlo preciso aquando da execução do código.
Outras técnicas para que o código tenha protecção em relação a módulos incluem:
org.eclipse.core.runtime.jobs.ILock
.
A vantagem de ILock
relativamente a bloqueios genéricos é que são transferidos automaticamente para o módulo da IU quando executam uma syncExec
e existe um suporte de detecção do impasse incorporado na respectiva implementação que regista e depois resolve os impasses.
Display.asyncExec
), que é processado integralmente no módulo da IU.
java.lang.String
e org.eclipse.core.runtime.IPath
tenham protecção em relação a módulos. A vantagem de objectos imutáveis é o acesso de leitura extremamente rápido, como resultado de um trabalho extra na modificação.
Os métodos seguintes foram eliminados da interface org.eclipse.ui.IWorkbenchPage. IWorkbenchPage está declarado na área de trabalho genérica, mas os métodos são inerentemente específicos de recursos.
Os clientes destes métodos IWorkbenchPage.openEditor devem chamar os métodos estáticos públicos correspondentes declarados na classe org.eclipse.ui.ide.IDE (no plug-in org.eclipse.ui.ide).
Os clientes deste método IWorkbenchPage.openSystemEditor(IFile) devem converter o IFile num IEditorInput, utilizando um novo FileEditorInput(IFile) e depois chamar o método openEditor(IEditorInput,String). Por outras palavras, reescreva page.openSystemEditor(file) comopage.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Nota: os clientes que utilizam o id de editor IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID têm de transmitir uma entrada de editor que implemente org.eclipse.ui.IPathEditorInput (que FileEditorInput implementa).
Nota: Trata-se de uma das incompatibilidades que não tem impacto na forma como os plug-ins binários 2.1 são executados pelo Eclipse 3.0.O Eclipse 3.0 inclui um mecanismo de compatibilidade de tempo de execução binário que assegura que os binários de plug-ins 2.1 existentes que utilizem qualquer um dos métodos eliminados openEditor e openSystemEditor continuem a trabalhar como no 2.1, apesar desta alteração da API. (Os métodos eliminados são efectivamente "adicionados de novo" pelo fragmento org.eclipse.ui.workbench.compatibility.)O método seguinte foi eliminado da interface org.eclipse.ui.IEditorPart. IEditorPart está declarado na área de trabalho genérica, mas o método é inerentemente específico de recurso.
Os clientes que chamarem este método devem em vez disso testar se a parte do editor é implementada ou se se adapta a org.eclipse.ui.ide.IGotoMarker (no plug-in org.eclipse.ui.ide) e se assim for, chamar gotoMarker(IMarker). A classe IDE tem um método conveniente para o fazer: IDE.gotoMarker(editor, marcação);
Os clientes que implementam um editor que se possa colocar com base na informação IMarker devem ser implementados ou adaptados para org.eclipse.ui.ide.IGotoMarker.Uma vez que o único método de IGotoMarker é gotoMarker(IMarker) e que tem a mesma assinatura e especificação que o antigo IEditorPart.gotoMarker(IMarker), as implementações de editor existentes podem adaptar-se a esta alteração simplesmente incluindo IGotoMarker na cláusula de implementações da definição da classe.
Um plug-in binário 2.1 com código que chame este método vai obter uma excepção de erro de criação de ligações de classes ao ser executado numa configuração padrão do Eclipse 3.0.
A interface do iniciador do editor org.eclipse.ui.IEditorLauncher é implementada por plug-ins que contribuem editores externos. O método seguinte foi removido desta interface. IEditorLauncher é declarado na área de trabalho genérica, mas o método é inerentemente específico de recurso.
Foi substituído por
Um plug-in binário 2.1 com código que chame este método vai obter uma excepção de erro de criação de ligações de classes ao ser executado numa configuração padrão do Eclipse 3.0.
Os métodos seguintes foram removidos da interface org.eclipse.ui.IEditorRegistry. IEditorRegistry é declarado na área de trabalho genérica, mas os métodos são inerentemente específicos do recurso.
Existem novas constantes que representam o editor externo do sistema e identificadores do editor no local (SYSTEM_EXTERNAL_EDITOR_ID e SYSTEM_INPLACE_EDITOR_ID). Estes dois editores necessitam de uma entrada de editor que seja implementada ou que se adapte a org.eclipse.ui.IPathEditorInput. Repare que o descritor do editor no local não vai existir nas configurações do Eclipse que não suportem edição no local.
O método seguinte foi eliminado da interface org.eclipse.ui.IWorkbench. IWorkbench está declarado na área de trabalho genérica, mas o método é inerentemente específico do recurso.
Um plug-in binário 2.1 com o código que chama este método irá obter uma excepção ao ser executado numa configuração padrão do Eclipse 3.0.
Para que o org.eclipse.ui.texteditor.AbstractTextEditor fique independente de IFile, org.eclipse.ui.texteditor.AbstractDocumentProvider introduz o conceito de uma operação fornecedora de documentos (DocumentProviderOperation) e de um executor da operação do fornecedor de documentos (IRunnableContext). Quando for solicitado que execute uma reposição, salvaguarda ou sincronização, AbstractDocumentProvider cria operações do fornecedor de documentos e utiliza o executor da operação para os executar. O contexto executável pode ser facultado pelas subclasses através do método getOperationRunner. De seguida é apresentado um resumo das alterações a que os clientes têm de ser adaptar:
A subclasse de AbstractDocumentProvider, org.eclipse.ui.editors.text.StorageDocumentProvider, implementa o método getOperationRunner para devolver sempre nulo. Isto significa que as subclasses de StorageDocumentProvider não devem ser afectadas por esta alteração.
A subclasse de StorageDocumentProvider, org.eclipse.ui.editors.text.FileDocumentProvider, implementa o método getOperationRunner que devolve um IRunnableContext para executar determinado DocumentProviderOperations dentro de uma WorkspaceModifyOperation. Outras alterações a FileDocumentProvider são:
Alterações a 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);
A subclasse de AbstractTextEditor, org.eclipse.ui.texteditor.StatusTextEditor, faculta o método predicado isErrorStatus(IStatus). As subclasses podem ser sobrepostas para decidirem se um determinado estado será considerado um erro ou não.
Alterações a org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:
Como parte da introdução do suporte de anotações sem cabeçalho, foram efectuadas as seguintes alterações a Anotação:
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
O Eclipse 3.0 tem novo suporte de consola genérica. A consola genérica está disponível através de Janela > Mostrar Vista > Básico > Consola e é utilizada pela depuração de Eclipse e pela integração de Ant.
O id da vista para a consola foi alterado de org.eclipse.debug.ui.ConsoleView para org.eclipse.ui.console.ConsoleView. Os plug-ins 2.1 que abrem programaticamente a consola não terão êxito porque a vista antiga já não existe.
No 3.0, os tipos de retorno para os métodos org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) e installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) mudaram de booleanos para int, de forma a permitir que os receptores votem "indiferente". Nas edições anteriores à 3.0, os receptores só podiam votar "suspender" ou "não suspender" quando fosse acertado um ponto de interrupção e "instalar" ou "não instalar" quando estivesse prestes a ser instalado um ponto de interrupção. No 3.0, os receptores também podem votar "indiferente" para qualquer uma destas notificações. Isto vai permitir que os clientes apenas votem de forma decisiva em situações do seu interesse. Em notificações de "acerto de ponto de interrupção", o ponto de interrupção será suspenso se os receptores votarem "suspender" ou se todos os receptores votarem "indiferente"; e não irá ser suspenso se pelo menos um dos receptores votar "não suspender" e nenhum receptor votar "suspender". Da mesma forma, em notificações de "instalação de ponto de interrupção", o ponto de interrupção será instalado se os receptores votarem para instalar ou se todos os receptores votarem "indiferente"; e não será instalado se pelo menos um dos receptores votar "não instalar" e nenhum receptor votar "instalar". Em geral, os implementadores devem devolver DONT_CARE excepto se tiverem algo a dizer de uma forma ou de outra. É importante ter presente, pro exemplo, que ao votar em "suspender" vai sobrepor o voto de qualquer outro receptor de "não suspender".
A interface IJavaBreakpointListener é implementada por clientes que criam ou reagem a pontos de interrupção no código Java. É provável que existam poucos clientes além das JDT, excepto o que comunicou o problema erro 37760) que esta alteração resolve. Trata.se de uma alteração de interrupção para o código existente que implementa a interface IJavaBreakpointListener. Este código tem de ser modificado para devolver um valor int adequado antes de ser compilado ou executado no 3.0.
Antes da 3.0, os métodos na classe de SWT, org.eclipse.swt.dnd.Clipboard, eram permitidos tacitamente para serem executados em módulos que não fossem o módulo da IU. Esta negligência resultou em falhas no GTK, onde o sistema operativo necessita que todas as interacções da área de transferência sejam executadas no módulo da IU. A negligência não foi revelada mais cedo porque muitas aplicações são de módulo único e recebem a maior parte dos seus testes em Windows. Para que a API da Área de Transferência seja sustentável em várias plataformas, no 3.0 a especificação e implementação de todos os métodos da API de Área de Transferência foram alteradas para lançar uma excepção SWT (ERROR_THREAD_INVALID_ACCESS), se forem invocadas de um módulo que não seja da IU. Os serviços da área de transferência são normalmente facultados automaticamente pelos componentes do Eclipse, como o editor de texto, que isolam muitos clientes da respectiva alteração de interrupção. O código existente que tem uma utilização directa da Área de Transferência deve assegurar que os métodos da API são chamados no módulo correcto, utilizando Display.asyncExec ou syncExec quando for apropriado, para mudar os acessos para o módulo da IU.
No 3.0, o SWT comunica eventos de tecla premida antes de ser efectuado o trabalho no SO. Isto ocorre muito antes do que ocorria antes do 3.0. Esta alteração foi efectuada para suportar associações de teclas no Eclipse que necessita de eventos de intercepção de teclas antes de qualquer widget ter a hipótese de processar o carácter. As consequências desta alteração são visíveis para o código que processa directamente eventos org.eclipse.swt.SWT.KeyDown de nível inferior. Por exemplo, significa que quando um receptor num widget de texto recebe um evento de tecla premida, o conteúdo do widget (getText()) ainda não irá incluir a tecla acabada de ser inserida (incluiria antes do 3.0). A forma recomendada de obter o texto completo do widget, incluindo a tecla actual, é processar os eventos SWT.Modify ou SWT.Verify de novel superior, em vez do evento SWT.KeyDown de nível inferior; o código que já funciona desta forma não será afectado por esta alteração.
Antes do 3.0, quando o foco estava na classe de SWT, org.eclipse.swt.widgets.Canvas ou numa das respectivas subclasses (incluindo widgets personalizados), ao inserir Ctrl+Tab, Shift+Tab, Ctrl+PgUp ou Ctrl+PgDn iria automaticamente activar a transversal para o widget seguinte/anterior sem comunicar um evento de teclas. Este comportamento não foi especificado e é executado contrariamente à regra que Canvases observa que cada tecla inseriu nelas. A forma correcta de processar transversal é registar um receptor transversal. Para suportar correctamente as associações de teclas do Eclipse no 3.0, o comportamento predefinido foi alterado para que Canvas agora observe eventos de teclas Ctrl+Tab, Shift+Tab, Ctrl+PgUp e Ctrl+PgDn em vez de transversais. Se utilizar um Canvas em bruto ou definir uma subclasse de Canvas, certifique-se de que regista um receptor transversal.
As selecções com o rato de itens nas classes de SWT, org.eclipse.swt.widgets.Table e Árvore, geram a sequência de eventos MouseDown-Selection-MouseUp uniformemente em todos os ambientes operativos. De forma semelhante, as selecções do teclado geram a sequência de eventos KeyDown-Selection-KeyUp uniformemente e todos os ambientes operativos. Antes do 3.0, a ordem dos eventos não era uniforme, com Motif e Photon em variante com o restante, comunicando sempre primeiro o evento de Selecção; ou seja, Selection-MouseDown-MouseUp ou Selection-KeyDown-KeyUp. No 3.0, a ordem de eventos em Motif e Photon foi alterada para corresponder às outras. O código existente que estava a funcionar correctamente em {Windows, GTK} e em {Motif, Photon} provavelmente não será afectado. Mas é sensato verificar o código para assegurar que não depende de uma ordem de eventos não válida.
org.eclipse.core.runtime.IStatus
tem uma nova constante de gravidade, IStatus.CANCEL
, que pode ser utilizada para indicar cancelamento.
Os chamadores deIStatus.getSeverity()
que dependem do conjunto de gravidades possíveis que estão a ser limitadas a IStatus.OK
,
INFO
, WARNING
e ERROR
são afectadas por esta adição. Os chamadores de getSeverity
devem actualizar o respectivo código para incluir a nova gravidade.
No Eclipse 3.0, as construções automáticas do espaço de trabalho agora ocorrem num módulo de segundo plano. Exige uma alteração do contrato da API para org.eclipse.core.resources.IResourceChangeEvent
. O contrato de IResourceChangeEvent
anteriormente garantia a seguinte ordenação de eventos para todas as alterações do espaço de trabalho:
PRE_DELETE
ou PRE_CLOSE
onde aplicávelPRE_AUTO_BUILD
POST_AUTO_BUILD
POST_CHANGE
Com a construção automática agora a ser executada em segundo plano, já não existem garantias sobre o relacionamento temporal entre eventosAUTO_BUILD
e o evento POST_CHANGE
. No Eclipse 3.0, os passos 3 a 5 na estrutura acima são removidos da operação. A figura resultante tem o seguinte aspecto:
PRE_DELETE
ou PRE_CLOSE
onde aplicávelPOST_CHANGE
Periodicamente, a plataforma vai executar uma operação de construção do espaço de trabalho em segundo plano. Repare que isto acontece independentemente do facto da construção automática estar ou não ligada. A altura exacta para a ocorrência desta construção não será especificada. A estrutura da operação de construção terá o seguinte aspecto:
PRE_BUILD
(PRE_BUILD
é o novo nome de PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
é o novo nome de POST_AUTO_BUILD)
POST_CHANGE
O ponto de referência para os deltas recebidos pelos receptores de construção automática será diferente nos receptores pós-alteração. Os receptores de construção vão receber a notificação de todas as alterações desde o final da última operação de construção. Os receptores pós-alteração vão receber um delta a descrever todas as alterações desde a última notificação pós-alteração. Esta nova estrutura retém três características dos receptores de alteração do recurso que se verificavam desde o Eclipse 1.0:
POST_CHANGE
recebem a notificação de absolutamente todas as alterações do recurso que ocorram durante a altura que são registados.
Isto vai incluir as alterações efectuadas pelos construtores e as alterações efectuadas por outros receptores.
PRE_AUTO_BUILD
recebem a notificação de todas as alterações do recurso, excepto as alterações efectuadas pelos construtores e os receptores da alteração do recurso.
POST_AUTO_BUILD
recebem notificações de todas as alterações do recurso, excepto as alterações efectuadas por outros receptores de POST_AUTO_BUILD
.
Contudo, existem algumas diferenças importantes nesta abordagem. Antes do Eclipse 3.0, os receptores de construção automática sempre foram chamados antes dos receptores de POST_CHANGE
.
Por este motivo, o delta recebido pelos receptores de construção automática sempre foi um subconjunto do delta recebi do pelos receptores dePOST_CHANGE
.
Este relacionamento agora está essencialmente reservado. Os receptores de construção automática vão receber um delta que é um sub-conjunto de todos os deltas facultados para os receptores dePOST_CHANGE
, desde o final da última construção de segundo plano.
Tal como antes, os receptores de construção automática terão permissão para modificar o espaço de trabalho, enquanto que os receptores pós-alteração não.
Já não se verificará esta situação na conclusão de uma operação de alteração do espaço de trabalho, que os receptores de eventos de AUTO_BUILD
para a qual os receptores de eventos foram notificados.
O código de clientes que regista os receptores da alteração de recursos com IWorkspace.addResourceChangeListener(IResourceChangeListener)
provavelmente não será afectado por esta alteração porque os eventos de AUTO_BUILD
nunca foram comunicados a estes receptores.
Contudo, os clientes que utilizamIWorkspace.addResourceChangeListener(IResourceChangeListener,int)
e especificam uma máscara de eventos que inclui eventos deAUTO_BUILD
, provavelmente serão interrompidos por esta alteração se tornarem conclusões sobre quando os receptores de construção automática são executados ou o módulo em que o são.
Por exemplo, se o receptor da construção automática estiver a actualizar um modelo de domínio para reflectir alterações para o espaço de trabalho, então esta actualização poderá não ter acontecido quando for devolvida a operação de alteração do espaço de trabalho.
É de notar que apenas o código ao nível da IU pode ser afectado desta forma.
O código ao nível do núcleo, que é chamado através da API, pode ser chamado no âmbito de um IWorkspaceRunnable
, por isso nunca se pode ter a certeza acerca de quando os receptores de alteração do recurso serão chamados. O ajuste sugerido para esta interrupção é utilizar POST_CHANGE
em vez de receptores de construção, caso seja necessário que a notificação ocorra antes da operação terminar.
Já não se poderá garantir que todas as alterações do recurso que ocorrem durante o âmbito dinâmico de um IWorkspaceRunnable
se processarão por lotes numa única notificação.
Este mecanismo ainda pode ser utilizado para processar alterações por lotes, de forma a evitar construções e notificações desnecessárias, mas a Plataforma pode agora decidir a execução de notificações durante a operação.
Esta alteração de contrato da API não é provável que seja uma alteração de interrupção para clientes existentes.
É o mesmo que a Plataforma decidir chamar IWorkspace.checkpoint
periodicamente durante operações de execução longas.
O motivo desta alteração é agora ser possível que vários módulos modifiquem simultaneamente o espaço de trabalho.
Quando um módulo terminar de modificar o espaço de trabalho, é necessária uma notificação para impedir os problemas de resposta, mesmo se a outra operação ainda não tiver terminado.
Esta alteração também permite que os utilizadores comecem a trabalhar num conjunto de recursos antes da operação terminar.
Por exemplo, agora um utilizador pode começar a procurar ficheiros num projecto que ainda esteja no processo de ser dada a respectiva saída.
O novo método IWorkspace.run(IWorkspaceRunnable,
ISchedulingRule, int, IProgressMonitor)
tem um sinalizador opcional, AVOID_UPDATE
, que as operações podem utilizar como uma sugestão para a plataforma para especificar se são pretendidas actualizações periódicas.
O que é afectado: Os plug-ins que contribuem extensões para o ponto de extensão org.eclipse.core.runtime.urlHandlers
.
Descrição: O contrato do ponto de extensão
org.eclipse.core.runtime.urlHandlers
foi alterado para utilizar o
serviço da Rotina de Tratamento de Sequência de URL facultado por OSGi. O
suporte de OSGi é superior ao do Eclipse 2.1 e processa correctamente as
rotinas de tratamento dinâmicas.
Devido a várias questões de concepção do mecanismo do parâmetro de
identificação do URL com base em Java, URLStreamHandlers registado com o
serviço da rotina de tratamento de OSGi tem de implementar
org.osgi.service.url.URLStreamHandlerService
.
Acção necessária: Antigamente, a classe da rotina de tratamento tinha de implementar java.net.URLStreamHandler
e expandir o ponto de extensão de urlHandlers.
O ponto de extensão já não é suportado e a rotina de tratamento tem de ser
actualizada para implementar a interface
org.osgi.service.url.URLStreamHandlerService
.
A estrutura de OSGi faculta uma classe de base abstracta(org.osgi.service.url.AbstractURLStreamHandlerService
) que pode ser normalmente colocada numa subclasse para cumprir esta função.
Em vez de registar a rotina de tratamento utilizando um ponto de extensão, os plug-ins agora têm de o fazer registando a sua rotina de tratamento como um serviço. Por exemplo,
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);
O que é afectado: Os plug-ins que fornecem pacotes facultados que, por sua vez, também são fornecidos por outros plug-ins. Um número muito limitado de plug-ins é afectado por esta alteração e alguns dos afectados, na verdade, irão beneficiar (consulte mais abaixo).
Descrição: No Eclipse 2.x, os carregadores de classes procuram classes pela seguinte ordem: consultar (1) carregador de classe ascendente (na prática, este é o carregador de classe de arranque Java), depois (2) os respectivo conteúdo do caminho de classes e, por fim, (3) todos os pré-requisitos na ordem declarada. O OSGi faculta uma optimização sobre este modelo. Nesta abordagem, um carregador de classe vai consultar (1) o carregador de classe ascendente (novamente, de forma efectiva o carregador de classe de arranque Java), depois (2a) um único pré-requisito conhecido por contribuir classes no pacote que está a ser consultado ou (2b) as respectivas entradas do caminho de classes para a classe pretendida.
O carregador de classes determina se vai consultar-se a si mesmo ou os respectivos pré-requisitos com base nos pacotes importados e necessários. Esta informação é inferida do conteúdo do plug-in, no caso de plug-ins tradicionais e directamente especificados, no caso de plug-ins com o manifesto do lote explícito de OSGi. Em qualquer dos casos, sabe-se a priori quais os carregadores de classes que vão facultar as classes para que pacotes. Isto vai facultar melhorias no rendimento, bem como uma solução para o problema complicado de ter vários pré-requisitos a contribuir as mesmas classes.
Veja, por exemplo, o caso de Xerces e Xalan, em que ambos contêm várias classes de pacotes org.xml. Ao utilizar a primeira abordagem, o plug-in de Xerces veria a respectiva cópia destas classes enquanto que o plug-in de Xalan veria a cópia de ambos. Uma vez que estes plug-ins têm de comunicar, ocorre ClassCastExceptions. Utilizando a segunda abordagem, apenas um dos dois plug-ins contribui as classes duplicadas e ambos os plug-ins vêm as mesmas cópias.
Acção necessária: A acção necessária depende das situações particulares deste caso de utilização. Os programadores afectados têm de rever o seu caminho de classes e resolver os conflitos existentes que podem surgir.
O que é afectado: Os plug-ins que esperam que o domínio de protecção do respectivo carregador de classe seja definido em todas as situações.
Descrição: No plug-in do Eclipse 2.1, os carregadores de classe eram java.security.SecureClassloaders e, desta forma, sempre teve um conjunto de domínios de protecção. No Eclipse 3.0, os carregadores de classe não expandem SecureClassloader e apenas definem o domínio de protecção se a segurança de Java estiver activada (não é o caso normal).
Acção necessária: A acção necessária vai depender da situação em que o plug-in esteja a utilizar o domínio de protecção.
O que é afectado: Os plug-ins que difundem objectos de tipo org.eclipse.core.runtime.IPlugin* para org.eclipse.core.runtime.model.Plugin*Model. Apesar do relacionamento entre estas interfaces e as classes de modelo não ser especificado na API do Eclipse 2.1, estamos explicitamente a chamar esta alteração, visto termos encontrado instâncias de plug-ins que dependem deste relacionamento a implementação do 2.1.
Descrição: A API do Eclipse faculta uma quantidade de interfaces (por exemplo, IPluginDescriptor
) e as chamadas classes de "modelo" (por exemplo, PluginDescriptorModel
) relacionadas com plug-ins e o registo do plug-in. Na implementação do Eclipse 2.1, acontece que as classes de modelo implementam as interfaces relevantes. No novo tempo de execução baseado em OSGi, o registo do plug-in foi retrabalhado de forma significativa para permitir uma separação entre o carregamento de classes e os aspectos de pré-requisitos de plug-ins e os aspectos da extensão e do ponto de extensão.
Desta forma, o tempo de execução do Eclipse 3.0 não consegue manter o relacionamento de implementação presente no 2.1.
Acção necessária: Os plug-ins que dependem deste relacionamento não de API têm de ser código retrabalhado segundo o respectivo caso de utilização. É facultada mais informação sobre este assunto na secção de alterações recomendadas deste documento e no Javadoc para as classes e métodos relacionados.
O que é afectado: Os plug-ins que utilizamorg.eclipse.core.runtime.ILibrary
.
Descrição: O novo tempo de execução mantém as entradas do caminho de classes num formato diferente e incompatível com o Eclipse. Como resultado, o nível de compatibilidade não consegue modelar correctamente as estruturas subjacentes de OSGi como objectos ILibrary. O suporte de compatibilidade do tempo de execução cria objectos ILibrary mas tem de assumir valores predefinidos para tudo, excepto o caminho da biblioteca.
Acção necessária: Os utilizadores de ILibrary devem considerar aceder aos valores de cabeçalho pretendidos (por exemplo, Bundle-Classpath
) do Lote apropriado (consulteBundle.getHeaders()
) e utilizar a classe de ajudaManifestElement
para interpretar as entradas.
Consulte o Javadoc de classe para obter mais detalhes.
O que é afectado: Os plug-ins que fizerem suposições relativamente à estrutura de instalação, localização e o esquema do sistema de ficheiros local.
Descrição: Os métodos comoIPluginDescriptor.getInstallURL()
devolvem URLs de um determinado formato. Apesar do formato não ser especificado, vários plug-ins estão a fazer suposições com base na implementação actual. Por exemplo, podem esperar obter um file:
manipulação do resultado de URL and use URL.getFile() and use java.io.File
.
Até à data, sempre foi uma abordagem funcionável mas algo frágil.
Por exemplo, se um plug-in estiver instalado num servidor web, é possível que seja devolvido um http:
URL. O novo tempo de execução do Eclipse 3.0 é ainda mais flexível e abre mais possibilidades para configurações de execução (por exemplo, manter plug-ins integrais em JARs em vez de expandidos nos directórios).
Ou seja, enquanto o novo tempo de execução baseado em OSGi não quebra realmente a API 2.1, vai expor mais casos em que as suposições efectuadas nos plug-ins actuais não são válidas.
Acção necessária: Os escritores de plug-ins devem certificar-se de que a informação a que têm de aceder está disponível através de getResource()
(e está no caminho de classes) ou utilizar a API relevante para aceder ao conteúdo de um plug-in
(por exemplo, Bundle.getEntry(String)
).
O que é afectado: O código não de plug-in que chama certos métodos da classe org.eclipse.core.boot.BootLoader
.
Descrição: Os métodos estáticos BootLoader.startup(), shutdown() e run() foram movidos para org.eclipse.core.runtime.adaptor.EclipseStarter, que faz parte da estrutura de OSGi. Esta API é a interface entre o main() em startup.jar e o tempo de execução da estrutura de OSGi/Eclipse. A reestruturação do tempo de execução não permite que estes métodos permaneçam em BootLoader. A antiga classe de BootLoader está agora localizada no nível de compatibilidade de tempo de execução e está desactualizada e os métodos movidos estão num apêndice para não fazerem nada.
Não existe substituição para a antiga BootLoader.getRunnable(), visto que o tempo de execução já não pode suportar a aquisição de aplicações individuais. Em vez disso, os utilizadores têm de indicar a aplicação do seu interesse quando iniciarem a plataforma.
Acção necessária: Em geral, esta API é utilizada pro muito poucas pessoas (não pode ser utilizada de um plug-in do Eclipse). No caso raro que aqui abordamos, o código tem de ser adaptado para utilizar os métodos correspondentes em EclipseStarter.
O que é afectado: Todos os plug-ins.
Descrição: No Eclipse 2.1, a linha bin.includes de um plug-in do respectivo build.properties não tem de conter a lista de JARs da declaração de bibliotecas no ficheiro plugin.xml; estes JARs foram adicionados automaticamente. No Eclipse 3.0, a lista de ficheiros na secção bin.includes de build.properties trata-se de uma lista exaustiva e tem de incluir todos os ficheiros que os programadores do plug-in querem que sejam incluídos no respectivo plug-in ao construir ou exportar.
Acção necessária: Certifique-se de que a linha bin.includes do ficheiro build.properties inclui todos os JARs listados no ficheiro plugin.xml.
O que é afectado: Os plug-ins que expõem a API que inclui elementos da API de tempo de execução alterada.
Descrição: Vários plug-ins expõem a API que inclui elementos da API de tempo de execução. Com as alterações ao tempo de execução do Eclipse 3.0 aqui descritas, os plug-ins cliente têm de reavaliar a sua utilização da API de tempo de execução na respectiva API.
Acção necessária: Esta situação é bastante rara, visto que muito pouco da API de tempo de execução do Eclipse está a alterar-se. Dependendo do cenário, os clientes poderão ter de alterar a API ou continuar a confiar no nível de compatibilidade.
O que é afectado: Os plug-ins que utilizamorg.eclipse.core.runtime.Platform.parsePlugins(...,
Factory).
Descrição: O método org.eclipse.core.runtime.Platform.parsePlugins(...,
Factory)
foi movido. A API associada ao argumento Factory foi movida do plug-in org.eclipse.core.runtime para o plug-in
org.eclipse.core.runtime.compatibility (que depende do plug-in de tempo de execução). Como resultado, o método de interpretação também foi movido.
Acção necessária: os utilizadores deste método devem utilizar o mesmo método na classe org.eclipse.core.runtime.model.PluginRegistryModel
.
O que é afectado: Os plug-ins que especificam código no respectivo caminho de classes mas que não facultam esse código (ou seja, o JAR é facultado por um fragmento; por exemplo, o plug-in org.eclipse.swt).
Descrição: O novo tempo de execução tem de converter os ficheiros plug.xml em ficheiros manifest.mf em segundo plano. Isto é realizado através de uma rígida transformação mecânica e uma análise dos jars listados e facultados pelo plug-in. No caso em que um plug-in especifica um jar no respectivo caminho de classes mas não faculta o jar, não existe código para analisar e o conversor do plug-in não pode gerar um manifest.mf correcto.
Acção necessária: Os fornecedores destes plug-ins têm de ser alterados para facultar o jar apropriado no próprio plug-in ou conceber/manter um ficheiro META-INF/MANIFEST.MF para o plug-in. Normalmente, esta acção poderá realizar-se utilizando PDE para obter o manifesto inicial e depois adicionando o cabeçalho Provide-Package adequado.
O que é afectado: Scripts (por exemplo, ficheiros Ant build.xml) que definem caminhos de classes que contêm jars relacionados com o tempo de execução e directórios de classes.
Descrição: O novo tempo de execução contém uma quantidade de novos plug-ins e jars. A sua introdução foi solicitada pela refactorização do tempo de execução para as partes configuráveis.
Na maioria das situações de tempo de execução, estas alterações são transparentes.
Contudo, se tiver scripts personalizados de build.xml (ou semelhantes) que actualmente compilem o código em relação a org.eclipse.core.runtime
, terá de os actualizar antes de funcionarem correctamente.
Um script normal contém uma entrada do caminho de classes numa tarefa <javac> que referencia o plug-inorg.eclipse.core.runtime
da seguinte forma:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
O plug-in de tempo de execução continua a conter muito do código de tempo de execução original.
Contudo, várias partes do tempo de execução que apenas lá estão por questões de
compatibilidade, estão contidas no plug-in de compatibilidade (org.eclipse.core.runtime.compatibility
).
A maior parte do novo código de tempo de execução está contida numa recolha de plug-ins (org.eclipse.osgi.*
).
Acção necessária: Os programadores devem adicionar as entradas abaixo conforme seja necessário para eliminar erros de compilação. Enquanto que o conjunto completo de jars facultado está listado abaixo, os utilizadores normais necessitam apenas de um subconjunto no caminho de classes na altura da compilação. Como sempre, a inclusão dos directórios /bin fica à escolha do utilizador. As entradas são aqui apresentadas em agrupamentos lógicos através do fornecimento do plug-in:
Além disso, os jars seguintes podem ser necessários em casos especiais:
Ao actualizar estes scripts, também deve ter a oportunidade de desmarcar (ou seja, remover) referências a org.eclipse.core.boot
. Este plug-in está desactualizado e já não contém qualquer código.
As entradas podem ficar no caminho de classes mas não servem qualquer propósito e devem ser removidas.
Observe para remover:
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
O que é afectado: Scripts (por exemplo, ficheiros Ant build.xml) utilizando a tarefa eclipse.buildScript.
Descrição: A Construção de PDE introduziu uma nova propriedades à tarefa eclipse.buildScript para controlar a geração de scripts de construção de plug-ins. Esta acção foi solicitada pela introdução do novo tempo de execução baseado em OSGi.
Acção necessária: Se quiser utilizar o Eclipse 3.0 para construir um produto baseado em 2.1, introduza no eclipse.buildScript a propriedade "buildingOSGi" e defina-a como falsa. Por exemplo:
<eclipse.buildScript ... buildingOSGi="false"/>
O que é afectado: Scripts (por exemplo, ficheiros Ant build.xml) utilizando a tarefa eclipse.buildScript.
Descrição: A Construção de PDE introduziu uma nova propriedades à tarefa eclipse.buildScript para controlar a geração de scripts de construção de plug-ins. Esta acção foi solicitada pela introdução do novo tempo de execução baseado em OSGi.
Acção necessária: Se quiser utilizar o Eclipse 3.0 para construir um produto baseado em 2.1, introduza em eclipse.buildScript a propriedade "buildingOSGi" e defina-a como falsa. Por exemplo:
<eclipse.buildScript ... buildingOSGi="false"/>
O que é afectado: Scripts (por exemplo, ficheiros Ant build.xml) utilizando a tarefa eclipse.buildScript.
Descrição: A Construção de PDE alterou o comportamento da tarefa eclipse.fetch para facilitar a construção do eclipse num estilo de construção automatizado. O estilo dos elementos agora suporta apenas uma entrada de cada vez e o scriptName é sempre ignorado.
Acção necessária: Se tivesse uma lista de entradas no identificador "elementos" de uma chamada eclipse.fetch, expanda-as por várias chamadas de eclipse.fetch. Se quiser definir o scriptName, repare que agora o script fetch gerado chama-se sempre "fetch_{elementId}". Por exemplo:
<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>
transforma-se em
<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../> <eclipse.fetch elements="feature@org.eclipse.platform" .../>
O ficheiro install.ini já não está incluído. No seu lugar está o novo ficheiro config.ini no sub-directório de configuração. Os produtos que utilizavam o ficheiro install.ini para especificar uma função principal (por exemplo, para facultar informação de marca) tem de efectuar alterações ao ficheiro config.ini. Além do novo nome do ficheiro, os nomes das chaves também foram alterados.
O valor da chave feature.default.id no 2.1 deve ser definido como o valor da nova chave do eclipse.product. O valor de eclipse.application deve ser definido para "org.eclipse.ui.ide.workbench".
Por fim, no 2.1 a imagem inicial sempre foi splash.bmp no directório de plug-ins da marca. No 3.0, a localização da imagem inicial é facultada explicitamente pela chave osgi.splashPath no ficheiro config.ini.