Incompatibilidades entre o Eclipse 2.1 e o 3.0

O Eclipse foi alterado nas áreas de incompatibilidade entre a versão 2.1 e 3.0 que afetam os plug-ins. As seguintes entradas descrevem as áreas que foram alteradas e fornecem instruções para migrar os plug-ins da 2.1 para a 3.0. Observe que você apenas precisará consultar estas informações se estiver tendo problemas para executar o plug-in da 2.1 na 3.0.

  1. Versão de Manifesto do Plug-in
  2. Reestruturação de Plug-ins da UI da Plataforma
  3. Reestruturação de Plug-ins de Tempo de Execução do Núcleo da Plataforma
  4. Remoção do Plug-in Xerces
  5. O Eclipse 3.0 é Mais Concorrente
  6. Abrindo Editores no IFiles
  7. Marcador Goto do Editor
  8. Ativador do Editor
  9. Registro do Editor
  10. Registro de Ajuda do Marcador do Workbench
  11. Provedores de Documentos do Editor de Texto
  12. Editores de Texto
  13. Suporte à Anotação Sem Título
  14. Visualização Console
  15. Listeners de Ponto de Interrupção Java
  16. Acesso da Área de Transferência no Encadeamento da UI
  17. Eventos de Teclas
  18. Passagem de Controles Personalizados com Tabulação
  19. Ordem de Eventos de Seleção na Tabela SWT e nos Widgets em Árvore
  20. Novo Nível de Gravidade em Objetos de Status
  21. Notificações de Alteração de Recursos Relacionados à Construção
  22. Notificações Intermediárias Durante Operações do Espaço de Trabalho
  23. Extensões de Rotina de Tratamento do Fluxo do URL
  24. Ordem de Carregamento de Classe
  25. Domínio de Proteção do Carregador de Classes Não Definido
  26. Distribuição do Objeto PluginModel
  27. Implementação de ILibrary Incompleta
  28. Suposições Inválidas Relacionadas a Formulários de URLs
  29. Métodos BootLoader Movidos/Excluídos
  30. A Exportação do Plug-in não Inclui os JARs do Plug-in Automaticamente
  31. Reexportando a API do Tempo de Execução
  32. Métodos de Análise de Plug-in na Plataforma
  33. Bibliotecas de Plug-ins Fornecidas por Fragmentos
  34. Alterações nos Scripts de Construção
  35. Alterações na Tarefa Ant de Construção do PDE
  36. Alterações na Tarefa Ant eclipse.build
  37. Alterações na Tarefa Ant eclipse.fetch
  38. Substituição de install.ini

1. Versão de Manifesto do Plug-in

O cabeçalho dos arquivos de manifesto para plug-ins (e fragmentos de plug-in) foi alterado para incluir uma nova linha que identifica a versão de manifesto adequada do plug-in. Antes da 3.0, os plug-ins não transportam nenhuma dessas linhas <?eclipse ...?>; após à 3.0, eles sempre precisarão ter uma. Essa alteração é para permitir que o tempo de execução do Eclipse reconheça confiavelmente os plug-ins anteriores à 3.0 que não foram transportados para a 3.0, portanto ele pode fornecer automaticamente maior compatibilidade binária para tais plug-ins. Esta é a forma geral do arquivo plugin.xml (o fragment.xml é similar):

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

Os manifestos de plug-ins criados pelo PDE 3.0 têm automaticamente essa forma. É extremamente recomendado que você utilize a ferramenta de migração de plug-in do PDE. Ela insere automaticamente a linha indicada no manifesto dos plug-ins e fragmentos de plug-ins da 2.1 e fornece várias outras alterações descritas aqui.

Se você incluir essa diretiva em um plugin.xml (manualmente ou utilizando o PDE), o arquivo também deverá ser atualizado para listar explicitamente os plug-ins dos quais ele depende. Por exemplo, antes do Eclipse 3.0 as dependências noorg.eclipse.core.runtime e no org.eclipse.core.boot eram implícitas. Com a versão 3.0, o org.eclipse.core.boot não é mais necessário e os desenvolvedores devem escolher o org.eclipse.core.runtime ou o org.eclipse.core.runtime.compatibility (ou nenhum), conforme adequado.

Nota: Essa é uma das incompatibilidades que não influenciam como os plug-ins binários da 2.1 são executados pelo Eclipse 3.0.

2. Reestruturação de Plug-ins da UI da Plataforma

O plug-in org.eclipse.ui, que era o plug-in principal da UI da plataforma, fornece agora apenas a API e os pontos de extensão para o workbench genérico (isto é, não específico ao IDE). A API e os pontos de extensão opcionais e específicos do IDE foram movidos para outros plug-ins.

O impacto dessa alteração é duplo: (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 requeridos foi alterada.

Os pontos de extensão org.eclipse.ui na seguinte tabela foram movidos para plug-ins diferentes, fazendo com que seus ids de ponto de extensão sejam alterados. Se um plug-in existente contribuir com uma extensão para os pontos de extensão movidos, então a referência no atributo "point" do elemento <extension> no arquivo de manifesto do plug-in deve ser alterada para fazer referência aos novos ids de ponto de extensão correspondentes. A ferramenta de migração de plug-in do PDE faz essas correções.

Nota: Essa é uma das incompatibilidades que não influenciam como os plug-ins binários da 2.1 são executados pelo Eclipse 3.0. O tempo de execução do Eclipse 3.0 detecta plug-ins anteriores à 3.0 (pela ausência da linha mencionada acima <?eclipse version="3.0"?> no manifesto do plug-in) e compensa automaticamente essas alterações no ponto de extensão e na dependência do plug-in.

ID de ponto de extensão antigo

Novo id de 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 seguinte tabela lista os pacotes da API anteriormente fornecidos 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.) Em alguns casos, os pacotes de APIs são agora divididos entre mais de um plug-in. Como as classes da API visíveis a qualquer plug-in específico são determinadas pela lista de plug-ins requeridos daquele plug-in, essas alterações poderão precisar de elementos "<requires>" de ajuste em um manifesto dos plug-ins existentes para obter novamente acesso à classe da API.

Essa alteração afeta apenas os plug-ins que dependem do plug-in org.eclipse.ui (ou seja, inclui <import plugin="org.eclipse.ui"/> na seção <requires> do manifesto do plug-in); todos os outros plug-ins não são afetados. Se eles forem afetados, você poderá precisar alterar o elemento <import> ou incluir elementos <import> adicionais, para que todas as classes da API que o plug-in precisar estejam no escopo. Recomendamos extremamente que os plug-ins apenas declarem dependências nos plug-ins que eles realmente utilizam. A inclusão de dependências desnecessárias reduz o desempenho de tempo de execução porque o carregador de classes Java deve procurar classes em todos os dependentes. (A ferramenta de migração de plug-in do PDE corrigirá as dependências e ajudará a determinar um conjunto mínimo.)

Pacote da API

Plug-in da 2.1

Correspondendo Plug-in(s) da 3.0

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

3. Reestruturação de Plug-ins de Tempo de Execução do Núcleo da Plataforma

O Tempo de Execução da Plataforma Eclipse 3.0 baseia-se no OSGi, necessitando de alterações na estrutura dos dois plug-ins de Tempo de Execução da Plataforma, o org.eclipse.core.runtime e o org.eclipse.core.boot.

Um novo plug-in org.eclipse.core.runtime.compatibility fornece uma ponte de implementação entre as APIs antigas e novas e é o novo local para várias APIs obsoletas antigamente localizadas no org.eclipse.core.runtime e no org.eclipse.core.boot. Os pontos de extensão do Tempo de Execução da Plataforma não são afetados pela reestruturação.

Ao migrar o plug-in existente para a 3.0, o manifesto do plug-in precisa ser atualizado para refletir a nova estrutura dos plug-ins de Tempo de Execução da Plataforma Eclipse. A ferramenta de migração de manifesto de plug-ins do PDE incluirá uma dependência no org.eclipse.core.runtime.compatibility, se necessário.

Observe também que se você marcar o plug-in como 3.0 (utilizando <?eclipse version="3.0"?>) e o plug-in definir uma classe Plugin, será necessário utilizar <import plugin="org.eclipse.core.runtime.compatibility"/> explicitamente no manifesto do plug-in ou se assegurar de que a classe Plugin defina o construtor padrão.

Nota: Essa é uma das incompatibilidades que não influenciam como os plug-ins binários da 2.1 são executados pelo Eclipse 3.0. O tempo de execução do Eclipse 3.0 detecta plug-ins anteriores à 3.0 (pela ausência da linha <?eclipse version="3.0"?> no manifesto do plug-in) e compensa automaticamente essas alterações no Tempo de Execução da Plataforma.

4. Remoção do Plug-in Xerces

Os plug-ins org.eclipse.xerces não são mais necessários e foram excluídos. O suporte à análise XML é construído no J2SE 1.4 e a presença do plug-in Xerces cria conflitos do carregador de classes. Os pacotes de API javax.xml.parsers, org.w3c.dom.* e org.xml.sax.* anteriormente fornecidos pelo plug-in org.eclipse.xerces agora estão disponíveis nas bibliotecas do J2SE.

Se o seu plug-in precisar do plug-in org.eclipse.xerces, você poderá alterar o manifesto do seu plug-in para remover essa dependência declarada. Feito isso, o código do plug-in deverá ser compilado e executado sem alterações adicionais.

Um plug-in binário da 2.1 com uma dependência declarada do plug-in org.eclipse.xerces estará sem um pré-requisito ao ser executado em uma configuração padrão do Eclipse 3.0. Como conseqüência, o plug-in não será ativado.

5. O Eclipse 3.0 é Mais Concorrente

Antes do Eclipse 3.0, o Eclipse operava na maior parte em um único encadeamento. A maioria dos métodos e pontos de extensão da API operavam no encadeamento da UI ou em um encadeamento gerado a partir de um diálogo de progresso que bloqueava o encadeamento da UI. A maioria dos escritores de plug-in não precisava se preocupar muito com a segurança do encadeamento, além de assegurar que toda a atividade da UI ocorria no encadeamento da UI. No Eclipse 3.0, em geral, há muito mais concorrência. Muitas operações agora ocorrem em um encadeamento de segundo plano, no qual eles podem estar executando concorrentemente com outros encadeamentos, incluindo o encadeamento da UI. Todos os plug-ins cujo código é executado em um encadeamento de segundo plano agora estão cientes da segurança do encadeamento de seu código.

Além dos plug-ins que estão executando explicitamente operações em segundo plano, utilizando a API org.eclipse.core.runtime.jobs, existem vários recursos e pontos de extensão da API da plataforma que utilizam os encadeamentos em segundo plano. Os plug-ins que apanham esses recursos precisam assegurar que seu código esteja protegido no encadeamento. A seguinte tabela resume a API e os pontos de extensão que executam parte ou todo o seu código em um encadeamento em segundo plano no Eclipse 3.0:

Ponto de extensão ou classe da API

Notas

org.eclipse.core.runtime.IRegistryChangeListener Novo 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.) Agora construído automaticamente em segundo plano
org.eclipse.core.resources.ISaveParticipant SNAPSHOT agora em segundo plano
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ponto de ext.) Novo no Eclipse 3.0, executado em segundo plano
org.eclipse.ui.decorators (ext. point) 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.) Novo 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á executado em segundo plano

Há várias estratégias disponíveis para tornar o encadeamento de código protegido. Uma solução simples é assegurar que todo o trabalho ocorra no encadeamento da UI, assegurando dessa forma uma execução serializada. Essa é uma abordagem comum para plug-ins da UI que não estão fazendo processamento intensivo da CPU. Ao fazer isso, saiba do risco de conflito inerente no Display.syncExec. Display.asyncExec é geralmente mais seguro porque ele não introduz o risco de conflito, à custa de perder o controle preciso quando o código é executado.

Outras técnicas para que o código fique protegido no encadeamento incluem:

6. Abrindo Editores no IFiles

Os seguintes métodos foram excluídos da interface org.eclipse.ui.IWorkbenchPage. O IWorkbenchPage está declarado no workbench genérico, mas os métodos são inerentemente específicos do recurso.

Os clientes desse 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 desse método IWorkbenchPage.openSystemEditor(IFile) devem converter o IFile em um IEditorInput utilizando novo FileEditorInput(IFile) e, em seguida, chamar o método openEditor(IEditorInput,String). Em outras palavras, reescrever page.openSystemEditor(file) como page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Nota: os clientes que utilizam o id do editor IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID devem transmitir uma entrada do editor que implemente o org.eclipse.ui.IPathEditorInput (que é feito pelo FileEditorInput).

Nota: Essa é uma das incompatibilidades que não influenciam como os plug-ins binários da 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-in existentes da 2.1, utilizando qualquer um dos métodos openEditor e openSystemEditor excluídos, continuarão a funcionar como na 2.1 apesar da alteração dessa API. (Os métodos detectados são efetivamente "incluídos de volta" pelo fragmento org.eclipse.ui.workbench.compatibility.)

7. Marcador Goto do Editor

O seguinte método foi excluído da interface org.eclipse.ui.IEditorPart. O IEditorPart está declarado no workbench genérico, mas os métodos são inerentemente específicos do recurso.

Os métodos correspondentes também foram excluídos das classes no pacote org.eclipse.ui.part que implementa o IEditorPart, isto é EditorPart, MultiEditor, MultiPageEditorPart e MultiPageEditor. 

Os clientes que chamam esse método devem testar se a parte do editor é implementada ou adaptada ao org.eclipse.ui.ide.IGotoMarker (no plug-in org.eclipse.ui.ide) e, se for, chamar o gotoMarker(IMarker). A classe IDE tem um método conveniente para fazer isso: IDE.gotoMarker(editor, marker);

Os clientes que implementam um editor que pode se posicionar com base nas informações do IMarker devem ser implementados ou adaptados ao org.eclipse.ui.ide.IGotoMarker.

Como o único método do IGotoMarker é o gotoMarker(IMarker) e tem a mesma assinatura e especificação do antigo IEditorPart.gotoMarker(IMarker), as implementações existentes do editor podem se adaptar a esta alteração incluindo simplesmente o IGotoMarker na cláusula de implementação da definição de classe.

Um plug-in binário da 2.1 com código que chama esse método obterá uma exceção de erro de vinculação de classe ao ser executado em uma configuração padrão do Eclipse 3.0.

8. Ativador do Editor

A interface do ativador do editor org.eclipse.ui.IEditorLauncher é implementada pelos plug-ins que contribuem com editores externos. O seguinte método foi removida dessa interface. O IEditorLauncher está declarado no workbench genérico, mas o método é inerentemente específico do recurso.

Foi substituído por

Os clientes que chamam o IEditorLauncher.open(file) devem chamar o IEditorLauncher.open(file.getLocation()). Os clientes que implementam essa interface devem substituir (ou aumentar) sua implementação de open(IFile) em um open(IPath).

Um plug-in binário da 2.1 com código que chama esse método obterá uma exceção de erro de vinculação de classe ao ser executado em uma configuração padrão do Eclipse 3.0.

9. Registro do Editor

Os seguintes métodos foram removidos da interface org.eclipse.ui.IEditorRegistry. O IEditorRegistry está declarado no workbench genérico, mas os métodos são inerentemente específicos do recurso.

Os clientes que chamam o getEditors(file) ou o getImageDescriptor(file) devem chamar os métodos "String" equivalentes: Os clientes que chamam o setDefaultEditor(IFile file, String editorId) e o getDefaultEditor(IFile file) 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): Além disso, o contrato da API para o método IEditorRegistrygetDefaultEditor() foi alterado. Esse método, que agora também está reprovado, sempre retornará o descritor do editor do Editor Externo do Sistema. Essa alteração influencia clientes que assumiram que o editor padrão retornado seria um editor de texto.

Existem novas constantes que representam o editor externo do sistema e os identificadores do editor no local (SYSTEM_EXTERNAL_EDITOR_ID e SYSTEM_INPLACE_EDITOR_ID). Esses dois editores requerem uma entrada no editor que seja implementada ou se adapte ao org.eclipse.ui.IPathEditorInput. Observe que o descritor do editor no local não existirá nas configurações do Eclipse que não suportam edição no local.

10. Registro de Ajuda do Marcador do Workbench

O seguinte método foi excluído da interface org.eclipse.ui.IWorkbench. O IWorkbench está declarado no workbench genérico, mas os métodos são inerentemente específicos do recurso.

Os clientes do IWorkbench.getMarkerHelpRegistry() devem chamar o método estático público org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (no plug-in org.eclipse.ui.ide).

Um plug-in binário da 2.1 com código que chama esse método obterá uma exceção ao ser executado em uma configuração padrão do Eclipse 3.0.

11. Provedores de Documentos do Editor de Texto

Para tornar o org.eclipse.ui.texteditor.AbstractTextEditor independente do IFile, o org.eclipse.ui.texteditor.AbstractDocumentProvider introduz o conceito de uma operação do provedor de documentos (DocumentProviderOperation) e um executor de operações do provedor de documentos (IRunnableContext). Quando solicitado a executar reconfiguração, salvamento ou sincronização, o AbstractDocumentProvider cria operações do provedor de documentos e utiliza o executor de operações para executá-las. O contexto executável pode ser fornecido pelas subclasses através do método getOperationRunner. A seguir, há um resumo das alterações às quais os clientes devem se adaptar:

A subclasse AbstractDocumentProvider org.eclipse.ui.editors.text.StorageDocumentProvider implementa o método getOperationRunner para sempre retornar nulo. Isso significa que as subclasses de StorageDocumentProvider não devem ser afetadas por essa alteração.

A subclasse StorageDocumentProvider org.eclipse.ui.editors.text.FileDocumentProvider implementa o método getOperationRunner que retorna um IRunnableContext para executar o DocumentProviderOperations determinado dentro de um WorkspaceModifyOperation. Outras alterações em FileDocumentProvider são:

12. Editores de Texto

Alterações em org.eclipse.ui.texteditor.AbstractTextEditor:

A subclasse org.eclipse.ui.texteditor.StatusTextEditor de AbstractTextEditor fornece o método predicado isErrorStatus(IStatus). As subclasses podem ser substituídas para decidir se um determinado status deve considerar um erro ou não.

Alterações em org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Suporte de Anotação Sem Título

Como parte da introdução de suporte à anotação sem título, as seguintes alterações foram feitas em Annotation:

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

14. Visualização Console

Eclipse 3.0 agora tem novo suporte ao console genérico. O console genérico está disponível através de Janela > Mostrar Visualização > Básica > Console e é utilizado pela depuração do Eclipse e integração do Ant.

O id da visualização para o console foi alterado de org.eclipse.debug.ui.ConsoleView para org.eclipse.ui.console.ConsoleView. Os plug-ins da 2.1 que abrem programaticamente o console não terão êxito porque a visualização antiga não existe mais.

15. Listeners de Ponto de Interrupção Java

Na 3.0, os tipos de retorno para os métodos org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) e installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) foram alterados de boolean to int para permitir que os listeners "não se preocupem". Em releases anteriores à 3.0, os listeners podiam votar para "suspender" ou "não suspender" quando um ponto de interrupção era atingido e "instalar" ou "não instalar" quando um ponto de interrupção estava prestes a ser instalado. Na 3.0, os listeners também podem votar para "não se preocupar" com nenhuma dessas notificações. Isso permite que os clientes apenas façam um voto decisivo em situações nas quais se preocupam. Para notificações de "ocorrência de ponto de interrupção", os pontos de interrupção serão suspensos se qualquer listener votar para "suspender" ou todos os listeners votarem para "não se preocupar"; e eles não serão suspensos se pelo menos um listener votar para "não suspender" e nenhum listener votar para "suspender". Da mesma forma, notificações de "instalação de ponto de interrupção", o ponto de interrupção será instalado se qualquer listener votar para instalar ou todos os listeners votarem para "não se preocupar"; e ele não será instalado ser pelo menos um listener votar para "não instalar" e nenhum listeners votar para "instalar". Em geral, os implementadores devem retornar DONT_CARE, a menos que tenham uma opinião convicta sobre uma forma ou outra. É importante saber, por exemplo, que a votação para "suspender" substituirá qualquer outro voto do listener para "não suspender".

A interface IJavaBreakpointListener é implementada por clientes que criam ou reagem a pontos de interrupção no código Java. Existem provavelmente alguns clientes além do próprio JDT; salve aquele que relatou o problema (erro 37760) que essa alteração será solucionada. Essa é uma alteração de interrupção para código existente que implementa a interface IJavaBreakpointListener. Esse código precisa ser modificado para retornar um valor int adequado antes dele ser compilado ou executado na 3.0.

16. Acesso da Área de Transferência no Encadeamento da UI

Antes da 3.0, a execução dos métodos na classe org.eclipse.swt.dnd.Clipboard do SWT era taticamente permitida em encadeamentos diferentes do encadeamento da UI. Esse engano resultava em falhas no GTK porque o sistema operacional precisa que todas as interações da área de transferência sejam executadas no encadeamento da UI. Isso não foi revelado antes porque muitos aplicativos têm encadeamento único e recebem a maior parte de seu teste no Windows. Para que a API da Área de Transferência fosse sustentável e entre plataformas, na 3.0 a especificação e a implementação de todos os métodos da API da Área de Transferência foram alterados para lançar uma Exceção do SWT (ERROR_THREAD_INVALID_ACCESS) se chamados a partir de um encadeamento não-UI. Os serviços da área de transferência são fornecidos automaticamente pelos componentes do Eclipse, como o editor de texto, que isola vários clientes de sua alteração de interrupção. O código existente que não faz uso direto da Área de Transferência deve assegurar que os métodos da API sejam chamados no encadeamento correto, utilizando Display.asyncExec ou syncExec quando adequado para deslocar acessos para o encadeamento da UI.

17. Eventos de Teclas

Na 3.0, o SWT relata eventos de teclas antes do trabalho ser concluído no S.O. Isso é bem anterior à 3.0. Essa alteração foi feita para suportar ligações de teclas no Eclipse que necessitam interceptar eventos de teclas antes de qualquer widget ter a chance de processar o caractere. As conseqüências dessa alteração são visíveis no código que manipula diretamente eventos org.eclipse.swt.SWT.KeyDown de nível baixo. Por exemplo, isso significa que quando um listener em um widget Text recebe um evento de tecla, o conteúdo do widget (getText()) ainda não incluirá a tecla que acabou de ser digitada (o teria feito antes da 3.0). A forma recomendada para obter o texto completo do widget, incluindo a tecla atual, é manipular o evento SWT.Modify ou SWT.Verify de nível superior em vez do evento SWT.KeyDown de nível baixo; o código que já faz isso dessa forma não é afetado por essa alteração.

18. Passagem de Controles Personalizados com Tabulação

Antes da 3.0, quando o foco estava na classe org.eclipse.swt.widgets.Canvas do SWT ou em uma de suas subclasses (incluindo widgets personalizados), a digitação de Ctrl+Tab, Shift+Tab, Ctrl+PgUp ou Ctrl+PgDn acionaria automaticamente a passagem para o widget seguinte/anterior sem relatar um evento de tecla. Esse comportamento não era especificado e executa o contador para a regra que os Canvases vêem cada tecla digitada neles. A forma adequada de manipular a passagem é registrando um listener de passagem. Para suportar adequadamente as ligações de teclas do Eclipse na 3.0, o comportamento padrão foi alterado de forma que o Canvas agora vê os eventos de teclas Ctrl+Tab, Shift+Tab, Ctrl+PgUp e Ctrl+PgDn em vez da passagem. Se aparecer um Canvas bruto ou você definir uma subclasse do Canvas, assegure-se de registrar um listener de passagem.

19. Ordem de Eventos de Seleção na Tabela SWT e nos Widgets em Árvore

As seleções de itens com o mouse nas classes org.eclipse.swt.widgets.Table e Tree do SWT geram a seqüência do evento MouseDown-Selection-MouseUp uniformemente em todos os ambientes operacionais. Similarmente, as seleções com o teclado geram a seqüência do evento KeyDown-Selection-KeyUp uniformemente em todos os ambientes operacionais. Antes da 3.0, a ordem dos eventos não era uniforme, com Motif e Photon em discordância com o restante, sempre relatando o evento Selection primeiro; isto é, Selection-MouseDown-MouseUp ou Selection-KeyDown-KeyUp. Na 3.0, a ordem dos eventos no Motif e no Photon foi alterada para corresponder aos outros. O código existente que estava funcionando corretamente no {Windows, GTK} e no {Motif, Photon} provavelmente não será afetado. Mas é melhor verificar o código para assegurar que ele não conte com uma ordem de evento inválida.

20. Novo Nível de Gravidade em Objetos de Status

O org.eclipse.core.runtime.IStatus tem uma nova constante de gravidade, IStatus.CANCEL, que pode ser utilizada para indicar cancelamento. Os responsáveis pela chamada de IStatus.getSeverity() que contam com o conjunto de gravidades possíveis sendo limitado para IStatus.OK, INFO, WARNING e ERROR são afetados por essa inclusão. Os responsáveis pela chamada de getSeverity devem atualizar seu código para incluir a nova gravidade.

21. Notificações de Alteração de Recursos Relacionados à Construção

No Eclipse 3.0, as construções automáticas do espaço de trabalho agora ocorrem em um encadeamento de segundo plano. Isso precisou de uma alteração de contrato da API para org.eclipse.core.resources.IResourceChangeEvent. O contrato de IResourceChangeEvent garantia anteriormente a seguinte ordem de eventos para todas as alterações no espaço de trabalho:

  1. Notificação do evento PRE_DELETE ou PRE_CLOSE se aplicável
  2. Executar a operação
  3. Notificação do evento PRE_AUTO_BUILD
  4. Se a construção automática estiver ativada, executar construção incremental do espaço de trabalho
  5. Notificação do evento POST_AUTO_BUILD
  6. Notificação do evento POST_CHANGE

Com a construção automática agora em execução no segundo plano, não há mais nenhuma garantia sobre o relacionamento temporal entre os eventos AUTO_BUILD e POST_CHANGE. No Eclipse 3.0, as etapas 3-5 na estrutura acima são removidas da operação. A imagem resultante se assemelha a esta:

  1. Notificação do evento PRE_DELETE ou PRE_CLOSE se aplicável
  2. Executar a operação
  3. Notificação do evento POST_CHANGE

Periodicamente, a plataforma executará uma operação de construção do espaço de trabalho no segundo plano. Observe que isso acontece independente da construção automática estar ativada ou desativada. O período exato de quanto essa construção ocorre não será especificado. A estrutura da operação de construção será semelhante a esta:

  1. Notificação do evento PRE_BUILD (PRE_BUILD é o novo nome para PRE_AUTO_BUILD)
  2. Se a construção automática estiver ativada, executar construção incremental do espaço de trabalho
  3. Notificação do evento POST_BUILD (POST_BUILD é o novo nome para POST_AUTO_BUILD)
  4. Notificação do evento POST_CHANGE

O ponto de referência para os deltas recebidos pelos listeners de construção automática será diferente dos listeners de pós-alteração. Os listeners de construção receberão notificação de todas as alterações desde o final da última operação de construção. Os listeners pós-alteração receberão um delta descrevendo todas as alterações desde a última notificação pós-alteração. Essa nova estrutura mantém três características de listeners de alteração de recurso que eram verdadeiras desde o Eclipse 1.0:

No entanto, há algumas diferenças importantes nessa abordagem. Antes do Eclipse 3.0, os listeners de construção automática eram sempre chamados antes dos listeners POST_CHANGE. Por essa razão, o delta recebido pelos listeners de construção automática eram sempre um subconjunto do delta recebido pelos listeners POST_CHANGE. Esse relacionamento agora é essencialmente reverso. Os listeners de construção automática recebem um delta que é um super conjunto de todos os deltas fornecidos para os listeners POST_CHANGE desde o final da última construção no segundo plano. Como ocorria antes, os listeners de construção automática poderão modificar o espaço de trabalho e os listeners pós-alteração não.

Não será mais verdade que na conclusão de uma operação de alteração do espaço de trabalho, os listeners do evento AUTO_BUILD terão sido notificados. O código do cliente que registra os listeners de alteração de recurso com IWorkspace.addResourceChangeListener(IResourceChangeListener) provavelmente não será afetado por essa alteração porque os eventos AUTO_BUILD nunca foram relatados para esses listeners. No entanto, os clientes que utilizam o IWorkspace.addResourceChangeListener(IResourceChangeListener,int) e especificam uma máscara de evento que inclui os eventos AUTO_BUILD, provavelmente serão interrompidos por essa alteração se eles fizerem suposições sobre quando os listeners de construção automática são executados ou em que encadeamento eles são executados. Por exemplo, se um listener de construção automática estiver atualizando um modelo de domínio para refletir as alterações no espaço de trabalho, então, essa atualização poderá não ter acontecido quando a operação de alteração do espaço de trabalho retornar. Vale a pena observar que apenas o código no nível da UI pode ser afetado dessa forma. O código no nível do núcleo que é chamado através da API pode ser chamado de dentro do escopo de um IWorkspaceRunnable, portanto, ele nunca poderá ter certeza sobre quando os listeners de alteração de recurso serão chamados. A correção sugerida para essa interrupção é utilizar POST_CHANGE em vez de construir listeners de construção, se for necessário que a notificação ocorra antes da operação ser concluída.

22. Notificações Intermediárias Durante Operações do Espaço de Trabalho

Não será mais garantido que todas as alterações de recurso que ocorrem durante o escopo dinâmico de um IWorkspaceRunnable ficarão em batch em uma única notificação. Esse mecanismo ainda pode ser utilizado para alterações em batch para evitar construções e notificações desnecessárias, mas agora a Plataforma poderá decidir executar notificações durante a operação. Essa alteração de contrato de API provavelmente não será uma alteração de interrupção para clientes existentes. Ele é equivalente à Plataforma decidir chamar o IWorkspace.checkpoint periodicamente utilizando operações de longa execução. A razão para essa alteração é que agora é possível para vários encadeamentos modificarem o espaço de trabalho simultaneamente. Quando um encadeamento termina de modificar o espaço de trabalho, é requerida uma notificação para evitar problemas de pronto atendimento, mesmo que outra operação ainda não tenha sido concluída. Essa alteração também permite que os usuários comecem a trabalhar em um conjunto de recursos antes da operação ser concluída. Por exemplo, agora um usuário pode estar começando a procurar arquivos em um projeto que ainda está no processo de ter um registro de 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 desejadas atualizações periódicas.

23. Extensões de Rotina de Tratamento do Fluxo do URL

O que é afetado: Plug-ins que contribuem com extensões para o ponto de extensão org.eclipse.core.runtime.urlHandlers.

Descrição: O contrato para o ponto de extensão org.eclipse.core.runtime.urlHandlers foi alterado para utilizar o serviço da Rotina de Tratamento do Fluxo de URL fornecido pelo OSGi. O suporte ao OSGi é superior àquele no Eclipse 2.1 e manipula corretamente rotinas de tratamento dinâmicas. Devido às várias questões de design com o mecanismo de base da rotina de tratamento de URL do Java, o URLStreamHandlers registrado com o serviço deve implementar o org.osgi.service.url.URLStreamHandlerService.

Ação requerida: Anteriormente, a classe da rotina de tratamento tinha de implementar java.net.URLStreamHandler e estender o ponto de extensão urlHandlers. O ponto de extensão não é mais suportado e a rotina de tratamento deve ser atualizada para implementar a interface org.osgi.service.url.URLStreamHandlerService. A estrutura OSGi fornece uma classe-base abstrata(org.osgi.service.url.AbstractURLStreamHandlerService) que pode ser trivialmente utilizada como uma subclasse para preencher essa função.

Em vez de registrar a rotina de tratamento utilizando um ponto de extensão, os plug-ins devem agora fazê-lo registrando 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);

24. Ordem de Carregamento de Classe

O que é afetado: Os plug-ins que fornecem pacotes que também são fornecidos por outros plug-ins. Um número bastante limitado de plug-ins são afetados por essa alteração e alguns dos afetados serão, na verdade, beneficiados (consulte abaixo).

Descrição: No Eclipse 2.x, os carregadores de classes procuram as classes na seguinte ordem: consultam (1) o carregador de classes pai (na prática, esse é o carregador de classes de inicialização Java), em seguida (2) seu próprio conteúdo do caminho de classe e, finalmente, (3) todos os seus pré-requisitos na ordem declarada. O OSGi oferece uma otimização sobre esse modelo. Nessa abordagem, um carregador de classes consultará (1) o carregador de classes pai (de novo efetivamente o carregador de classes de inicialização Java), em seguida, (2a) um único pré-requisito conhecido para contribuir com classes no pacote que está sendo consultado ou (2b) suas próprias entradas de caminho de classe para a classe desejada.

O carregador de classes determina se irá consultar a si mesmo ou seus pré-requisitos com base em seus pacotes importados e requeridos. Essas informações são concluídas a partir do conteúdo do plug-in, no caso de plug-ins tradicionais, e especificadas diretamente, no caso de plug-ins com manifesto explícito de pacote configurável do OSGi. Nos dois casos, sabe-se a priori quais carregadores de classe fornecerão as classes e para quais pacotes. Isso oferece aprimoramentos de desempenho, bem como uma solução para o problema de vários pré-requisitos que contribuem para as mesmas classes.

Utilize, por exemplo, o caso de Xerces e Xalan, em que os dois contêm várias classes dos pacotes org.xml. Utilizando a primeira abordagem, o plug-in Xerces veria sua cópia dessas classes, enquanto o plug-in Xalan veria a cópia delas. Como esses plug-ins precisam se comunicar, ocorre ClassCastExceptions. Utilizando a segunda abordagem, apenas um dos dois plug-ins contribui com as classes duplicadas e os dois plug-ins vêem as mesmas cópias.

Ação requerida: A ação requerida depende da particularidade do caso de uso. Os desenvolvedores afetados precisam revisar seu caminho de classe e resolver todos os conflitos que podem estar acontecendo.

25. Domínio de Proteção do Carregador de Classes Não Definido

O que é afetado: Plug-ins que esperam que o domínio de proteção de seu carregador de classes seja sempre definido.

Descrição: Os carregadores de classes de plug-in do Eclipse 2.1 eram java.security.SecureClassloaders e, como tais, sempre têm um conjunto de domínio de proteção. No Eclipse 3.0, os carregadores de classes não estendem SecureClassloader e apenas definem o domínio de proteção se a segurança Java estiver ativada (não é o caso normal).

Ação requerida: A ação requerida dependerá do cenário em que o plug-in está utilizando o domínio de proteção.

26. Distribuição do Objeto PluginModel

O que é afetado: Os plug-ins que distribuem objetos do tipo org.eclipse.core.runtime.IPlugin* para org.eclipse.core.runtime.model.Plugin*Model. Embora o relacionamento entre essas interfaces e as classes de modelo não seja especificado na API do Eclipse 2.1, estamos chamando explicitamente essa alteração porque localizamos instâncias de plug-ins contando com esse relacionamento na implementação da 2.1.

Descrição: A API do Eclipse fornece uma série de interfaces (por exemplo, IPluginDescriptor) e as chamadas classes de "modelo" (por exemplo, PluginDescriptorModel) relacionadas a plug-ins e ao registro de plug-in. Na implementação do Eclipse 2.1 o que acontece é que as classes de modelo implementam as interfaces pertinentes. No novo tempo de execução baseado no OSGi, o registro do plug-in foi significativamente retrabalhado para permitir uma separação entre o carregamento de classe e os aspectos de pré-requisito de plug-ins e a extensão e os aspectos do ponto de extensão. Como tal, o tempo de execução do Eclipse 3.0 não pode manter o relacionamento de implementação presente na 2.1.

Ação requerida: Os plug-ins que contam com esse relacionamento não-API precisam ter o código retrabalhado de acordo com seu caso de uso. Informações adicionais são fornecidas na seção de alterações recomendadas deste documento e no Javadoc para classes e métodos relacionados.

27. Implementação de ILibrary Incompleta

O que é afetado: Plug-ins que utilizam o org.eclipse.core.runtime.ILibrary.

Descrição: O novo tempo de execução mantém as entradas de caminho de classe em uma forma diferente e incompatível do Eclipse. Como resultado, a camada de compatibilidade não pode modelar corretamente as estruturas subjacentes do OSGi, como objetos ILibrary. O suporte de compatibilidade do tempo de execução cria objetos ILibrary, mas deve assumir valores padrão para tudo, exceto para o caminho da biblioteca.

Ação requerida: Usuários do ILibrary devem considerar acessar os valores de cabeçalho desejados (por exemplo, Bundle-Classpath) no Pacote Configurável adequado (consulte Bundle.getHeaders()) e utilizar a classe de assistente ManifestElement para interpretar as entradas. Consulte o Javadoc da classe para obter detalhes adicionais.

28 Suposições Inválidas Relacionadas a Formulários de URLs

O que é afetado: Os plug-ins que fazem suposições relacionadas à sua estrutura de instalação, ao local e ao layout do sistema de arquivos local.

Descrição: Métodos como IPluginDescriptor.getInstallURL() retornam URLs de uma forma específica. Apesar de sua forma não estar especificada, vários plug-ins estão fazendo suposições com base na implementação atual. Por exemplo, eles podem esperar obter um URL file:, utilizar URL.getFile() e utilizar a manipulação java.io.File no resultado. Para data, essa abordagem foi viável, mas um tanto frágil. Por exemplo, se um plug-in estiver instalado em um servidor da Web, é possível que um URL http: seja retornado. 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 inteiros nos JARs em vez de explodidos nos diretórios). Ou seja, enquanto o novo tempo de execução baseado no OSGi não interrompe realmente a API da 2.1, ele expõe mais casos onde as suposições feitas nos plug-ins atuais são inválidas.

Ação requerida: Os escritores de plug-ins asseguram que as informações que eles precisam acessar estão disponíveis através de getResource() (e estão no caminho de classe) ou utilizam a API pertinente para acessar o conteúdo de um plug-in (por exemplo, Bundle.getEntry(String)).

29. Métodos BootLoader Movidos/Excluídos

O que é afetado: Código que não é de plug-in que chama determinados métodos da classe org.eclipse.core.boot.BootLoader.

Descrição: Os métodos estáticos BootLoader.startup(), shutdown() e run() foram movidos para o org.eclipse.core.runtime.adaptor.EclipseStarter, que faz parte da estrutura do OSGi. Essa API é a interface entre main() no startup.jar e a estrutura do OSGi/tempo de execução do Eclipse. A reestruturação do tempo de execução não permitiu que esses métodos permanecessem no BootLoader. Agora a classe BootLoader antiga está localizada na camada de compatibilidade de tempo de execução e foi reprovada e os métodos movidos foram retirados para não fazer nada.

Não há substituição para o BootLoader.getRunnable() antigo porque o tempo de execução não suporta mais a aquisição de aplicativos individuais. Em vez disso, os usuários devem indicar o aplicativo de interesse quando iniciarem a plataforma.

Ação requerida: Em geral, esta API é utilizada por poucas pessoas (ela não pode ser utilizada a partir de um plug-in do Eclipse). No raro caso em que isso acontece, o código deve ser adaptado para utilizar os métodos correspondentes no EclipseStarter.

30. A Exportação do Plug-in não Inclui os JARs do Plug-in Automaticamente

O que é afetado: Todos os plug-ins.

Descrição: No Eclipse 2.1, uma linha bin.includes do plug-in de seu build.properties não tinha de conter a lista de JARs de sua declaração de biblioteca no arquivo plugin.xml; esses JARs foram incluídos gratuitamente. No Eclipse 3.0, a lista de arquivos na seção bin.includes do build.properties é uma lista exaustiva e deve incluir todos os arquivos que os desenvolvedores de plug-in pretendem que sejam incluídos em seu plug-in ao construir ou exportar.

Ação requerida: Assegure-se de que a linha bin.includes do arquivo build.properties inclua todos os JARs listados no arquivo plugin.xml.

31. Reexportando a API do Tempo de Execução

O que é afetado: 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 do tempo de execução. Com as alterações no tempo de execução do Eclipse 3.0 descritas aqui, os plug-ins de clientes devem reavaliar seu uso da API de tempo de execução em sua API.

Ação requerida: Esse cenário é raro porque muito pouco da API de tempo de execução do Eclipse é alterado. Dependendo do cenário, os clientes podem precisar alterar sua API ou continuar a contar com a camada de compatibilidade.

32. Métodos de Análise de Plug-in na Plataforma

O que é afetado: Plug-ins que utilizam o org.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 até o plug-in org.eclipse.core.runtime.compatibility (que depende do plug-in de tempo de execução). Como resultado, o método de análise também foi movido.

Ação requerida: Usuários desse método devem utilizar o mesmo método na classe org.eclipse.core.runtime.model.PluginRegistryModel.

33. Bibliotecas de Plug-ins Fornecidas por Fragmentos

O que é afetado: Plug-ins que especificam código em seu caminho de classe, mas não fornecem código (isto é, o JAR é fornecido por um fragmento; por exemplo, o plug-in org.eclipse.swt).

Descrição: O novo tempo de execução deve converter arquivos plug.xml para arquivos manifest.mf atrás dos bastidores. Isso é feito através de um transformação matemática direta e uma análise dos jars listados e fornecidos pelo plug-in. No caso em que um plug-in especifica um jar em seu caminho de classe, mas não fornece o jar, não há código para análise e o conversor do plug-in não pode gerar um manifest.mf correto.

Ação requerida: Os provedores de tais plug-ins devem ser alterados para fornecer o jar adequado no próprio plug-in ou lidar/manter um arquivo META-INF/MANIFEST.MF para seu plug-in. Normalmente, isso pode ser feito utilizando o PDE para obter o manifesto inicial e, em seguida, incluindo no cabeçalho Provide-Package adequado.

34. Alterações nos Scripts de Construção

O que é afetado: Os scripts (por exemplo, arquivos build.xml do Ant) que definem caminhos de classe que contêm jars e diretórios de classe relacionados ao tempo de execução.

Descrição: O novo tempo de execução contém uma série de novos plug-ins e jars. Sua introdução foi administrada pela refatoração do tempo de execução em partes configuráveis. Para a maioria das situações de tempo de execução, essas alterações são transparentes. No entanto, se você tiver scripts build.xml (ou similares) personalizados que compilam código atualmente no org.eclipse.core.runtime, você precisará atualizá-los antes deles funcionarem corretamente. Um script típico contém uma entidade de caminho de classe em uma tarefa <javac> que faz referência ao plug-in org.eclipse.core.runtime como segue:

    ../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. No entanto, várias partes do tempo de execução que estão lá apenas para fins de compatibilidade estão contidas em um plug-in de compatibilidade (org.eclispe.core.runtime.compatibility). A maioria do novo código de tempo de execução está contida em uma coleta de plug-ins (org.eclipse.osgi.*).

Ação requerida: Os desenvolvedores devem incluir as entradas abaixo conforme necessário para eliminar erros de compilação. Enquanto o conjunto completo de jars fornecidos está listado abaixo, usos típicos requerem apenas um subconjunto no caminho de classe no tempo de compilação. Normalmente, a inclusão dos diretórios /bin é arbitrária. As entradas são fornecidas aqui em agrupamentos lógicos fornecendo o plug-in:

Além disso, os seguintes jars poderão ser requeridos em casos especiais:

Enquanto estiver atualizando tais scripts, você também deverá obter a oportunidade de limpar (isto é, remover) referências ao org.eclipse.core.boot. Esse plug-in está obsoleto e não contém mais código. As entradas podem ser deixadas no caminho de classe, mas elas não têm nenhum objetivo e devem ser removidas. Veja como remover:

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

35. Alterações na Tarefa Ant de Construção do PDE

O que é afetado: Os scripts (por exemplo, arquivos build.xml do Ant) utilizando a tarefa eclipse.buildScript.

Descrição: A construção do PDE introduziu uma nova propriedade à tarefa eclipse.buildScript para controlar a geração de scripts de construção de plug-ins. Isso foi administrado pela introdução do novo tempo de execução baseado no OSGi.

Ação requerida: Se você quiser utilizar o Eclipse 3.0 para construir um produto baseado na 2.1, então, introduza no eclipse.buildScript a propriedade "buildingOSGi" e defina-a para false. Exemplo:

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

36. Alterações na Tarefa Ant eclipse.build

O que é afetado: Os scripts (por exemplo, arquivos build.xml do Ant) utilizando a tarefa eclipse.buildScript.

Descrição: A construção do PDE introduziu uma nova propriedade à tarefa eclipse.buildScript para controlar a geração de scripts de construção de plug-ins. Isso foi administrado pela introdução do novo tempo de execução baseado no OSGi.

Ação requerida: Se você quiser utilizar o Eclipse 3.0 para construir um produto baseado na 2.1, então, introduza no eclipse.buildScript a propriedade "buildingOSGi" e defina-a para false. Exemplo:

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

37. Alterações na Tarefa Ant eclipse.fetch

O que é afetado: Os scripts (por exemplo, arquivos build.xml do Ant) utilizando a tarefa eclipse.buildScript.

Descrição: A Construção do PDE alterou o comportamento da tarefa eclipse.fetch para facilitar a construção do eclipse em um estilo de construção automatizado. O estilo de elementos agora suporta apenas uma entrada por vez e o scriptName é sempre ignorado.

Ação requerida: Se você tiver uma lista de entradas na marcação "elements" de uma chamada eclipse.fetch, espalhe-as através de várias chamadas do eclipse.fetch. Se você utilizá-las para definir o scriptName, observe que agora o script fetch gerado sempre será chamado de "fetch_{elementId}". Exemplo:

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

torna-se

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

38. Substituição de install.ini

O arquivo install.ini não está mais incluído. Em seu local está o novo arquivo config.ini no subdiretório de configuração. Os produtos que utilizavam o arquivo install.ini para especificar um recurso primário (por exemplo, para fornecer informações de marca) precisam fazer alterações no arquivo config.ini. Além do novo nome de arquivo, os nomes das chaves foram alterados.

O valor da chave feature.default.id na 2.1 deve ser definido como o valor da nova chave eclipse.product. O valor do eclipse.application deve ser definido para "org.eclipse.ui.ide.workbench".

Finalmente, na 2.1 a imagem para a imagem splash era sempre splash.bmp no diretório de plug-ins de marca. Na 3.0, o local da imagem splash é fornecido explicitamente pela chave osgi.splashPath no arquivo config.ini.