Por que o Eclipse API foi alterado de formas incompatíveis entre 2.1 e 3.0?
O Eclipse 3.0 é uma evolução do Eclipse 2.1. Havia poucas áreas em que não podíamos desenvolver o Eclipse enquanto mantinha a compatibilidade perfeita na placa. As quatro origens principais das incompatibilidades são:
A lista de incompatibilidades específicas.
Um plug-in do 2.1 funcionará no Eclipse 3.0?
Sim, exceto em alguns casos. Se um plug-in conta somente com as APIs do Eclipse 2.1, ele continuará a funcionar no 3.0. As poucas exceções são locais na API em que as alterações entre 2.1 e 3.0 não puderam ser feitas de qualquer modo compatível; se um plug-in utiliza um desses, não funcionará.
Meu plug-in 2.1 faz uso de classes nos pacotes internos. Ainda funcionará no Eclipse 3.0?
Se um plug-in conta com classes internas ou um comportamento não especificado na API do Eclipse 2.1, é impossível fazer adivinhações de um jeito ou de outro sobre se o plug-in pode funcionar no 3.0. Você precisará experimentar.
Como executar um plug-in no Eclipse 3.0 sem tocá-lo?
Instale o plug-in 2.1 no subdiretório eclipse/plugins/ de um produto com base em Eclipse 3.0-e reinicie o Eclipse. O Eclipse reconhecerá que o plug-in é um plug-in 2.1 não convertido (pelo cabeçalho no plugin.xml) e automaticamente fazer ajustes para compensar as alterações para as dependências do plug-in da Plataforma e dos pontos de extensão da Plataforma renomeados.
Um plug-in 2.1 precisará ser alterado para compilar adequadamente no Eclipse 3.0?
Sim, em todos os casos. Há determinadas diferenças entre o Eclipse 2.1 e o 3.0 que precisam de alterações em todos os plug-ins em avanço. Se você tem um plug-in gravado para 2.1 e deseja recompilá-lo, ele precisa ser migrado para 3.0 antes que possa ser desenvolvido além do 3.0.
Como migrar o plug-in para o Eclipse 3.0?
Depois de ter carregado (ou importado) seu projeto de plug-in para um espaço de trabalho do Eclipse 3.0, utilize as Ferramentas PDE > Migrar para 3.0 (menu de contexto do projeto) para converter a manifestação do plug-in para o formato 3.0 e automaticamente ajustar a lista de plug-ins da Plataforma requerida e as referências para os pontos de extensão da Plataforma que foram renomeados. Na maioria dos casos, o código para o plug-in deve ser compilado e executado com êxito. O código para o plug-in deve ser revisado para certificar-se de que não é dependente de uma das áreas de alteração da API compatível.
É possível confiar que um plug-in terá erros compilados ou avisos se contar com API que tenha alterado a incompatibilidade?
Há algumas áreas de alteração incompatível que não são sinalizadas pelo compilador Java.
É possível ignorar seguramente os avisos no código vindo da utilização de API reprovada?
Sim, em curto prazo. Sempre que possível, as APIs obsoletas são marcadas como reprovadas em vez de serem excluídas completamente e continuarem a funcionar (apesar de possivelmente somente em condições limitadas). Enquanto não há urgência para eliminar a API reprovada, o fato de que agora é considerada obsoleta significa que há uma maneira melhor de fazer alguma coisa. Os plug-ins devem ser privados de todo o uso para API reprovada na primeira conveniência.
Depois de migrar o plug-in para o Eclipse 3.0, ainda é possível instalar e executar o plug-in binário resultante no Eclipse 2.1?
Isso não é suportado e provavelmente não funcionaria por causa dos pontos de extensão renomeados.
Qual é a finalidade de org.eclipse.core.runtime.compatibility?
A movimentação em 3.0 para um tempo de execução com base em OSGi tornou algumas APIs do tempo de execução de núcleo existente obsoletas. Sempre que possível, as APIs obsoletas nos pacotes org.eclipse.core.runtime.*, junto com a implementação por trás delas, são movidas do plug-in org.eclipse.core.runtime para um novo plug-in org.eclipse.core.runtime.compatibility. Por padrão, os plug-ins recentemente criados dependem de org.eclipse.core.runtime e espera-se que sejam utilizadas somente APIs de tempo de execução não-reprovadas. Por outro lado, os plug-ins existentes migrando do 2.1 dependerão, por padrão, do org.eclipse.core.runtime.compatibility e podem fazer uso das APIs antigas também (o plug-in de org.eclipse.core.runtime.compatibility exporta APIs do org.eclipse.core.runtime novamente). Enquanto o plug-in de org.eclipse.core.runtime.compatibility provavelmente é incluído nas configurações do Eclipse IDE, é provável que não seja incluído nos produtos com base nas configurações de RCP.
Qual é a finalidade de org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility é um fragmento de plug-in que fornece compatibilidade binária aprimorada para os plug-ins 2.1 sendo executados em um produto com base no Eclipse 3.0. No 3.0, seis métodos com uma dependência explícita no IFile ou IMarker foram movidos da interface do org.eclipse.ui.IWorkbenchPage para separar claramente o workbench do espaço de trabalho e dos recursos. O fragmento de org.eclipse.ui.workbench.compatibility organiza tudo para que esses métodos sejam incluídos novamente para que os plug-ins 2.1 existentes possam ser executados sem modificação. No entanto, observe que os plug-ins sendo migrados para 3.0 que fazem referência aos métodos movidos consultarão erros de compilação que podem (somente) ser resolvidos chamando os métodos de substituição localizados no org.eclipse.ui.ide.IDE.
O métodos IWorkbenchPage em questão são: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) e openSystemEditor(IFile).