Esta seção descreve as alterações que serão necessárias se você estiver tentando alterar o plug-in 3.1 para adotar os mecanismos e as APIs 3.2.
O Eclipse 3.2 oferece nova infra-estrutura para associar configurações de ativação a recursos. Esse mapeamento permite à plataforma executar filtragem baseada em recursos das configurações de ativação e opcionalmente excluir as configurações de ativação quando um projeto associado é excluído. O diálogo de ativação foi aperfeiçoado para suportar um conjunto de filtros para opcionalmente ocultar as configurações associadas a projetos fechados e excluídos. Além disso, o diálogo de ativação suporta filtragem com base nos conjuntos de tarefas selecionados na janela ativa do ambiente de trabalho, que também pode ser selecionada no diálogo de ativação.
É responsabilidade de um cliente gerenciar o mapeamento de recursos para configurações
de ativação. A API foi incluída em ILaunchConfigurationWorkingCopy
para
definir os recursos associados a uma configuração e também em
ILaunchConfiguration
para obter os recursos associados a uma configuração. Por
exemplo, guias de ativação, atalhos de ativação e participantes de recriação devem ser
levados em conta durante a migração. O código que cria ou modifica as configurações de
ativação também devem atualizar os mapeamentos de recursos.
O Eclipse 3.2 oferece nova infra-estrutura para migrar configurações de ativação para
compatibilidade com o novo conjunto de ferramentas. Por exemplo, no Eclipse 3.2, foi
incluído suporte para executar a filtragem baseada em recursos das configurações de
ativação. É necessário fazer upgrade das configurações de ativação para fornecer
mapeamentos de recursos visando alavancar esse novo recurso. Os usuários podem
migrar manualmente as configurações de ativação em seu espaço de trabalho na página
de preferências
Executar/Depurar > Ativação > Configurações de Ativação,
pressionando o botão Migrar.
Um novo atributo opcional de delegação de migração foi incluído no ponto de extensão
launchConfigurationTypes
, especificando uma classe que implementa a nova
interface ILaunchConfigurationMigrationDelegate
. Uma delegação de migração é
responsável por identificar os candidatos a migração e migrá-los.
Um novo atributo opcional foi incluído no ponto de extensão launchModes
para suportar adequadamente a externalização de rótulos de ações de menu de
ativação em cascata. Os clientes que contribuem com modos de ativação devem
especificar o rótulo apropriado a ser utilizado para menus de ativação em cascata,
como "Executar Como". O novo atributo é chamado launchAsLabel
. Rótulos
apropriados foram fornecidos pela plataforma para os modos de ativação de perfil,
depuração e execução. Para compatibilidade inversa, quando o novo atributo não é
especificado para um modo de ativação, os rótulos de menu em cascata são gerados como
antes, via MessageFormat com "{0} As
". Consulte o erro relacionado
105235.
ICU4J é um conjunto de bibliotecas Java que fornece suporte mais abrangente para Unicode, globalização e internacionalização de software. Para fornecer essa funcionalidade para a comunidade do Eclipse, foi incluído o ICU4J no build da plataforma do Eclipse 3.2. Você o verá no build como um plug-in denominado com.ibm.icu. A plataforma do Eclipse utilizará APIs ICU no Eclipse 3.2.
A migração de códigos do aplicativo pode ser feita de forma incremental, significando que não é necessária a adoção total de todas as funções do ICU4J para se aproveitar os benefícios da utilização do ICU4J. Veja a página do ICU4J no wiki do Eclipse para obter mais detalhes sobre como migrar seu código para utilizar o ICU4J.
A inclusão do plug-in do ICU4J adiciona a ordem de 3 MB ao rodapé. Alguns aplicativos podem não absorver o ICU4J se o tamanho do aplicativo tiver precedência sobre a adoção da função do ICU4J. Se for esse o caso, um plug-in de substituição(com.ibm.icu.base) estará disponível na página do build da plataforma do Eclipse. Faça download do plug-in, remova o plug-in com.ibm.icu e sua contraparte de origem do diretório /plugins e coloque-o no plug-in de substituição. Isso é necessário, porque a plataforma do Eclipse adotou as APIs ICU para 3.2, portanto simplesmente remover o plug-in do ICU resultaria em erros de compilação no código da plataforma. O plug-in de substituição tem aproximadamente 100 KB e só é chamado para a implementação do JDK padrão das classes e APIs utilizadas com mais freqüência no ICU4J. Novamente, você pode ler apágina do ICU4J no wiki do Eclipse para obter mais detalhes sobre como migrar seu código para utilizar o ICU4J.
Para suportar o ICU4J no JFace, algumas criações criativas de API foram necessárias para impedir a referência a classes ICU na API. Isso resultou na inclusão de:
org.eclipse.jface.viewers.ViewerComparator
, da
qual org.eclipse.jface.viewers.ViewerSorter
agora é uma subclasse.org.eclipse.jface.viewers.StructuredViewer
,
para suportar a inclusão de org.eclipse.jface.viewers.ViewerComparator
.A classe ViewerSorter
tem um método público getCollator()
que retorna um java.text.Collator
. Como esse método é a API, ele não pode simplesmente ser alterado para utilizar um ICU Collator. Além disso, as classes ICU não podem fazer parte da API (assinaturas), pois uma dependência direta de plug-in no ICU impediria que o JFace fosse utilizado de forma independente (com o SWT). Para acomodar essas restrições, foi incluída a classe ViewerComparator
que utiliza um java.util.Comparator
, em vez de um ICU Collator. Isso foi feito porque a classe do ICU Collator implementa java.util.Comparator
, portanto qualquer StructuredViewer
agora pode utilizar o ICU Collator em vez dejava.text.Collator
, mas o JFace não precisa incluir uma dependência no plug-in do ICU4J.
Esses dois novos métodos foram incluídos no suporte StructuredViewer
utilizando o ICU Collator para classificar o conteúdo do visualizador por meio de umViewerComparator
, em vez de um ViewerSorter
. É recomendado que qualquer StructuredViewer
agora utilize esses métodos para obter/definir o classificador (comparador) do visualizador, em vez dos métodos getSorter()
e setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
O pacote configurável org.eclipse.equinox.common inclui diversas novas
classes de API (por exemplo, Assert
e ListenerList
) que têm
nomes comuns. Se o código tiver uma classe com o mesmo nome e utilizar instruções import
* para importar a classe local e as classes do tempo de execução, você poderá obter a
seguinte mensagem de erro:
O tipo ABC é ambíguo
A organização das importações e a escolha da origem de importação apropriada devem resolver esse problema.
Como resultado do código sendo movido para novos plug-ins de tempo de execução, scripts customizados que fazem referência explicitamente a org.eclispe.core.runtime poderão precisar incluir um ou mais dos seguintes plug-ins: