Incompatibilidades entre o Eclipse 2.1 e o 3.0

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.

  1. Versão de manifesto do plug-in
  2. Reestruturação dos plug-ins da IU da plataforma
  3. Reestruturação dos 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 simultâneo
  6. Abrir editores em IFiles
  7. Marcação goto do editor
  8. Iniciador do editor
  9. Registo do editor
  10. Registo da ajuda da marcação da área de trabalho
  11. Fornecedores de documentos do editor de texto
  12. Editores de texto
  13. Suporte de anotações sem cabeçalho
  14. Vista Consola
  15. Receptores de ponto de interrupção de Java
  16. Acesso da área de transferência no módulo da IU
  17. Eventos de tecla premida
  18. Transversal de separador de controlos personalizados
  19. Ordem de eventos de selecção na tabela SWT e nos widgets em árvore
  20. Novo nível de gravidade nos objectos do estado
  21. Notificações de alteração do recurso relacionadas com a construção
  22. Notificações intermédias durante as operações de espaço de trabalho
  23. Extensões da rotina de tratamento de sequência de URL
  24. Ordem de carregamento de classes
  25. Domínio de protecção do carregador de classe não definido
  26. Difusão do objecto PluginModel
  27. Implementação de ILibrary incompleta
  28. Suposições não válidas relativamente ao formato de URLs
  29. Métodos BootLoader movidos/eliminados
  30. A exportação do plug-in não inclui os JARs do plug-ins automaticamente
  31. Voltar a exportar a API de tempo de execução
  32. Métodos de interpretação do plug-in na Plataforma
  33. Bibliotecas do plug-in facultadas por fragmentos
  34. Alterações para construir scripts
  35. Alterações à tarefa Ant de construção de PDE
  36. Alterações à tarefa eclipse.build Ant
  37. Alterações à tarefa eclipse.fetch Ant
  38. Substituição de install.ini

1. Versão de manifesto do plug-in

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.

2. Reestruturação dos plug-ins da IU da plataforma

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

3. Reestruturação dos plug-ins de tempo de execução do núcleo da plataforma

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.

4. Remoção do plug-in Xerces

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.

5. O Eclipse 3.0 é mais simultâneo

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:

6. Abrir editores em IFiles

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.)

7. Marcação goto do editor

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 métodos correspondentes também foram eliminados das classes no pacote org.eclipse.ui.part, que implementa IEditorPart, nomeadamente EditorPart, MultiEditor, MultiPageEditorPart e MultiPageEditor. 

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.

8. Iniciador do editor

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

Os clientes que chamam IEditorLauncher.open(file) devem em vez disso chamar IEditorLauncher.open(file.getLocation()). Os clientes que implementam esta interface devem substituir (ou acrescentar) a sua implementação de open(IFile) por uma de open(IPath).

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.

9. Registo do editor

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.

Os clientes que chamam getEditors(file) ou getImageDescriptor(file) devem chamar os métodos "String" equivalentes: Os clientes que chamam setDefaultEditor(IFile file, String editorId) e getDefaultEditor(IFile file) devem em vez disso 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, foi modificado o contrato da API para o método IEditorRegistrygetDefaultEditor(). Este método, que agora também está obsoleto, irá sempre devolver o descritor do editor Editor Externo do Sistema. Esta alteração vai ter impacto nos clientes que assumiram que o editor predefinido devolvido seria um editor de texto.

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.

10. Registo da ajuda da marcação da área de trabalho

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.

Os clientes do IWorkbench.getMarkerHelpRegistry() devem em vez disso 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 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.

11. Fornecedores de documentos do editor de texto

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:

12. Editores de texto

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

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:

13. Suporte de anotações sem cabeçalho

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

14. Vista Consola

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.

15. Receptores de ponto de interrupção de Java

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.

16. Acesso da área de transferência no módulo da IU

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.

17. Eventos de tecla premida

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.

18. Transversal de separador de controlos personalizados

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.

19. Ordem de eventos de selecção na tabela SWT e nos widgets em árvore

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.

20. Novo nível de gravidade nos objectos do estado

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.

21. Notificações de alteração do recurso relacionadas com a construção

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:

  1. Notificação de eventos PRE_DELETE ou PRE_CLOSE onde aplicável
  2. Execute a operação
  3. Notificação de eventos PRE_AUTO_BUILD
  4. Se a construção automática estiver activada, execute a construção incremental do espaço de trabalho
  5. Notificação de eventos POST_AUTO_BUILD
  6. Notificação de eventos 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:

  1. Notificação de eventos PRE_DELETE ou PRE_CLOSE onde aplicável
  2. Execute a operação
  3. Notificação de eventos POST_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:

  1. Notificação de eventos PRE_BUILD (PRE_BUILD é o novo nome de PRE_AUTO_BUILD)
  2. Se a construção automática estiver activada, execute a construção incremental do espaço de trabalho
  3. Notificação de eventos POST_BUILD (POST_BUILD é o novo nome de POST_AUTO_BUILD)
  4. Notificação de eventos 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:

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.

22. Notificações intermédias durante as operações do espaço de trabalho

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.

23. Extensões da rotina de tratamento de sequência de URL

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);

24. Ordem de carregamento de classes

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.

25. Domínio de protecção do carregador de classe não definido

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.

26. Difusão do objecto PluginModel

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.

27. Implementação de ILibrary incompleta

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.

28 Suposições não válidas relativamente ao formato de URLs

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)).

29. Métodos BootLoader movidos/eliminados

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.

30. A exportação do plug-in não inclui automaticamente os JARs do plug-in

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.

31. Voltar a exportar a API de tempo de execução

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.

32. Métodos de interpretação do plug-in na Plataforma

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.

33. Bibliotecas do plug-in facultadas por fragmentos

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.

34. Alterações para construir scripts

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

35. Alterações à tarefa Ant de construção de PDE

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"/>

36. Alterações à tarefa eclipse.build Ant

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"/>

37. Alterações à tarefa eclipse.fetch Ant

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" .../>

38. Substituição de install.ini

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.