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.
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.
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 |
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.
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.
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:
org.eclipse.core.runtime.jobs.ILock
.
A vantagem de ILock
sobre travas genéricas é que ele é transferido
automaticamente para o encadeamento da UI ao fazer um syncExec
e há
um suporte à detecção de conflitos construído em sua implementação que registra e,
então, resolve os conflitos.Display.asyncExec
), que é
processada inteiramente no encadeamento da UI.java.lang.String
e org.eclipse.core.runtime.IPath
, fiquem protegidas no encadeamento. A vantagem de
objetos imutáveis é o acesso de leitura extremamente rápido, à custa de trabalho extra
na modificação.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.)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 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.
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
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.
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.
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.
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.
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.
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:
Alterações em org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
A subclasse 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:
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
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.
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.
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.
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.
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.
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.
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.
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:
PRE_DELETE
ou PRE_CLOSE
se aplicávelPRE_AUTO_BUILD
POST_AUTO_BUILD
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:
PRE_DELETE
ou PRE_CLOSE
se aplicávelPOST_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:
PRE_BUILD
(PRE_BUILD
é o novo nome para PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
é o novo nome para POST_AUTO_BUILD)
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:
POST_CHANGE
recebem notificação de absolutamente todas as
alterações de recursos que ocorrem durante o período em que são registradas. Isso
inclui alterações feitas por construtores e alterações feitas por outros listeners.PRE_AUTO_BUILD
recebem notificação de todas as alterações de
recurso, exceto das alterações feitas pelos construtores e listeners de
alterações de recurso.
POST_AUTO_BUILD
recebem notificação de todas as alterações
de recurso, exceto das alterações feitas por outros listeners POST_AUTO_BUILD
.
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.
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.
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);
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.
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.
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.
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.
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)
).
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.
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.
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.
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
.
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.
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
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"/>
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"/>
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" .../>
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.