FAQ de Migração de Plug-ins do Eclipse 3.0

Porque é que a API do Eclipse mudou de formas incompatíveis entre o 2.1 e o 3.0?

O Eclipse 3.0 é uma evolução do Eclipse 2.1. Existem algumas áreas onde não pudemos melhorar o Eclipse mantendo ainda assim uma compatibilidade perfeita entre as várias versões. As quatro principais fontes de incompatibilidades são:

A lista de incompatibilidades específicas.

Um plug-in de 2.1 vai funcionar no Eclipse 3.0?

Sim, excepto nalguns casos. Se um plug-in depender apenas das APIs do Eclipse 2.1, então vai continuar a trabalhar no 3.0. As poucas excepções são locais na API onde não foi possível efectuar as alterações entre o 2.1 e o 3.0 de nenhuma forma compatível; se um plug-in utilizar qualquer um destes, não vai funcionar.

Muitos plug-ins de 2.1 utilizam classes em pacotes internos. Mesmo assim, irá funcionar no Eclipse 3.0?

Se um plug-in depender das classes internas ou do comportamento não especificado na API do Eclipse 2.1, é impossível afirmar com segurança se o plug-in poderá funcionar ou não no 3.0. Vai ter de experimentar.

Como executo o meu plug-in no Eclipse 3.0 sem lhe tocar?

Instale o plug-in 2.1 no subdirectório eclipse/plugins/ de um produto baseado no Eclipse 3.0 e reinicie o Eclipse. O Eclipse vai reconhecer que o plug-in é um plug-in 2.1 não convertido (pelo cabeçalho de plugin.xml) e realizar ajustes automáticos para compensar as alterações às dependências de plug-in de plataforma e a pontos de extensão da plataforma com o nome mudado.

Um plug-in 2.1 tem de ser alterado para ser compilado correctamente no Eclipse 3.0?

Sim, em todos os casos. Existem algumas diferenças entre o Eclipse 2.1 e o 3.0 que requerem que se apliquem alterações a todos os plug-ins. Se tiver um plug-in escrito para 2.1 e quiser recompilá-lo, este terá de ser migrado para o 3.0 antes de poder ser programado para o 3.0.

Como posso migrar o meu plug-in para o Eclipse 3.0?

Uma vez que tenha carregado (ou importado) o seu projecto de plug-in para um espaço de trabalho do Eclipse 3.0, utilize Ferramentas de PDE > Migrar para o 3.0 (menu de contexto do projecto) para converter o manifesto do plug-in para o formato 3.0 e ajustar automaticamente a lista de plug-ins de plataforma requeridos e referências a pontos de extensão da plataforma cujo nome tenha sido mudado. 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 revisto para assegurar que não está dependente de uma das áreas de alterações incompatíveis da API.

Posso esperar que um plug-in tenha erros e avisos de compilação se este depender da API cuja incompatibilidade foi alterada?

Não. Existem algumas áreas de alterações incompatíveis que não são sinalizadas pelo compilador Java.

Posso ignorar em segurança os avisos do código que chegam da utilização da API obsoleta?

Sim, a curto prazo. Sempre que possível, as APIs obsoletas são marcadas como desactualizadas em vez de serem eliminadas directamente e continuam a trabalhar (só é possível sob condições limitadas). Por isso, ao mesmo tempo que não existe nenhuma urgência em eliminar a API, o facto de agora se considerar obsoleta significa que agora temos mais meios para tomar uma atitude. Os Plug-ins devem prescindir de toda a utilização da API desactualizada o mais rápido possível.

Uma vez que tenha migrado o meu plug-in para o Eclipse 3.0, ainda posso instalar e executar o plug-in binário resultante no Eclipse 2.1?

Não. Isto não é suportado e provavelmente não vai funcionar devido aos pontos de extensão com o nome mudado.

Qual é o objectivo de org.eclipse.core.runtime.compatibility?

O movimento de 3.0 para um tempo de execução baseado em OSGi tornou obsoletas algumas das APIs de tempo de execução do núcleo existentes. Sempre que possível, as APIs obsoletas nos pacotes org.eclipse.core.runtime.*, juntamente com a implementação por trás dela, foram movidas do plug-in de org.eclipse.core.runtime para um novo plug-in de org.eclipse.core.runtime.compatibility. Por predefinição, os plug-ins recém-criados dependem de org.eclipse.core.runtime e espera-se que utilizem apenas APIs de tempo de execução não desactualizadas. Por outro lado, os plug-ins existentes que migram do 2.1 vão depender por predefinição de org.eclipse.core.runtime.compatibility e podem utilizar as antigas APIs também (o plug-in de org.eclipse.core.runtime.compatibility volta a exportar as APIs de org.eclipse.core.runtime). Enquanto que é provável que o plug-in de org.eclipse.core.runtime.compatibility seja incluído nas configurações de IDE do Eclipse, é evidentemente improvável que seja incluído em produtos baseados em configurações de RCP.

Qual é o objectivo de org.eclipse.ui.workbench.compatibility?

org.eclipse.ui.workbench.compatibility é um fragmento de plug-in que faculta compatibilidade binária melhorada para plug-ins 2.1 que estejam a ser executados num produto com base em Eclipse 3.0. No 3.0, seis métodos com uma dependência explícita de IFile ou IMarker foram movidos da interface org.eclipse.ui.IWorkbenchPage para separar de forma clara a área de trabalho do espaço de trabalho e dos recursos. O fragmento org.eclipse.ui.workbench.compatibility consegue adicionar de novo estes métodos para que os plug-ins 2.1 existentes possam ser executados sem modificações. Contudo, repare que os plug-ins que estiverem a ser migrados para o 3.0 que remetem para os métodos movimentados irão ver erros de compilação que podem (apenas) ser resolvidos chamando os métodos de substituição, agora localizados emorg.eclipse.ui.ide.IDE.

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