Esta secção descreve as alterações que são necessárias se estiver a tentar alterar o plug-in 3.1 para adoptar o mecanismo e as APIs do 3.2.
O Eclipse 3.2 faculta uma nova infra-estrutura para associar as configurações de lançamento aos recursos. Esta correlação permite que a plataforma execute filtrações baseadas em recursos nas configurações de lançamento e que, opcionalmente, elimine essas configurações quando for eliminado um projecto a elas associado. A caixa de diálogo de lançamento foi aperfeiçoada de forma a suportar um conjunto de filtros para ocultar opcionalmente as configurações associadas a projectos fechados e eliminados. Do mesmo modo, a caixa de diálogo de lançamento suporta a filtração baseada nos conjuntos de trabalho seleccionados na janela activa da área de trabalho, que também pode ser seleccionada na caixa de diálogo de lançamento.
É da responsabilidade do cliente gerir a correlação das configurações de lançamento.
A API foi adicionada a ILaunchConfigurationWorkingCopy
, para
definir os recursos associados à configuração, e a
ILaunchConfiguration
, para obter os recursos associados à configuração. Por exemplo, os separadores de lançamento, os atalhos de lançamento e os
participantes de refactorização deverão ser considerados aquando da migração. O
código que cria ou modifica as configurações de lançamento devem também
actualizar as correlações dos recursos.
O Eclipse 3.2 faculta uma nova infra-estrutura para migrar as configurações
de lançamento, para que se sejam compatíveis com ferramentas novas. Por
exemplo, no Eclipse 3.2, foi adicionado suporte para executar o filtro baseado
em recursos nas configurações de lançamento. As configurações de lançamento
necessitam de ser actualizadas, de modo a facultarem correlações de recursos
para explorar esta nova função. Os utilizadores podem migrar manualmente as
configurações de lançamento no espaço de trabalho a partir da página de
preferências
Executar/Depurar > Lançamento > Configurações de Lançamento,
ao premir o botão Migrar.
Um novo atributo delegado de migração opcional foi adicionado ao ponto de
extensão launchConfigurationTypes
, especificando uma
classe que implementa a nova interface ILaunchConfigurationMigrationDelegate
.
Um delegado de migração é responsável pela identificação e migração de candidatos de
migração.
Um novo atributo opcional foi adicionado ao ponto de extensão
launchModes
para suportar adequadamente a exteriorização das
etiquetas de acção dos submenus de lançamento. Os clientes que contribuem
com modos de lançamento, devem especificar a etiqueta adequada para a
utilização de submenus de lançamento, tais como "Executar Como". O novo atributo
denomina-se launchAsLabel
. As etiquetas adequadas são
facultados pela plataforma para executar, depurar e perfilar os modos de lançamento.
Para haver compatibilidade com outras edições, quando o novo atributo não é
especificado para um modo de lançamento, as etiquetas do submenu são
geradas do mesmo modo que anteriormente, através do MessageFormat com "{0}
As
".
Consulte o erro relacionado 105235.
O ICU4J é um conjunto de bibliotecas Java que faculta um suporte mais abrangente para Unicode e para a globalização e internacionalização de software. Para facultar esta funcionalidade à comunidade do Eclipse, o ICU4J foi adicionado à plataforma construída para o Eclipse 3.2. Poderá visualizá-lo na construção como sendo um plug-in denominado com.ibm.icu. A plataforma do Eclipse utilizará as API do ICU no Eclipse 3.2.
A migração do código de aplicação pode ser feito incrementalmente, o que significa que a completa adopção da função ICU4J não é necessária para recolher os benefícios da utilização do ICU4J. Consulte a página ICU4J no Eclipse wiki, para mais detalhes sobre como migrar o código para utilizar o ICU4J.
A adição do plug-in do ICU4J adiciona na ordem do 3MB à nota de rodapé. Algumas aplicações poderão não desejar absorver o ICU4J, caso o tamanho da aplicação tenha precedência sobre a adopção da função ICU4J. Se for o caso, está disponível um plug-in de substituição (com.ibm.icu.base) a partir da página de construção da plataforma Eclipse. Descarregue o plug-in, remova o plug-in com.ibm.icu e os respectivos duplicados de origem a partir do /directório de plug-ins e largue-o no plug-in de substituição. Este procedimento é necessário uma vez que a plataforma Eclipse adoptou as API do UCI para a versão 3.2. Por conseguinte, a simples remoção do plug-in do ICU resultará na compilação de erros no código da plataforma. O plug-in de substituição tem um tamanho cerca de 100KB e simplesmente chama através da implementação do JDK predefinido das classes e APIs mais utilizadas no ICU4J. Mais uma vez, pode consultar a página ICU4J no Eclipse wiki, para mais detalhes sobre a utilização do plug-in de substituição de ICU.
Para suportar o ICU4J no JFace, tornou-se necessária a existência de algumas adições de API criativas para evitar a referência às classes de ICU na API. Isto resultou na adiçã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 adição
de org.eclipse.jface.viewers.ViewerComparator
.A classe ViewerSorter
contém um método público
getCollator()
que apresenta um java.text.Collator
.
Uma vez que este método é API, não poderia simplesmente ser alterado para
utilizar o ICU Collator.
As classes ICU também não podem fazer parte do API (assinaturas) do mesmo modo
que uma dependência directa do plug-in no ICU iria evitar que o JFace fosse
utilizado em modo autónomo (com SWT). Para acomodar estas restrições, foi
adicionada a classe ViewerComparator
que utiliza o
java.util.Comparator
, em vez de uma Intercaladora do ICU. Este procedimento
foi realizado uma vez que a classe da Intercaladora do ICU implementa o
java.util.Comparator
, e, por conseguinte, qualquer
StructuredViewer
pode utilizar a Intercaladora do ICU em vez de
java.text.Collator
, mas o JFace não tem de adicionar uma
dependência no plug-in do ICU4J.
Os dois novos métodos adicionados ao suporte StructuredViewer
ao
utilizar a Intercaladora do ICU de modo a ordenar os conteúdos do visualizador
através de uma ViewerComparator
, em vez de um
ViewerSorter
. É recomendado que qualquer
StructuredViewer
utilize estes métodos de modo a obter/definir o
ordenador do visualizador (comparador), em vez de utilizar os métodos
getSorter()
e setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
O agrupamento org.eclipse.equinox.common inclui várias classes
novas da API (por exemplo, Assert
e ListenerList
),
que têm nomes comuns. Se o seu código contiver uma classe com o mesmo nome e
utilizar instruções de importação * para importar a classe local e as classes
do tempo de execução, poderá ser-lhe apresentada a seguinte mensagem de erro:
O tipo ABC é ambíguo
A organização das importações e a selecção da origem de importação adequada deverão resolver este problema.
Como consequência da deslocação do código para novos plug-ins de tempo de execução, os scripts personalizados que referenciam explicitamente o org.eclispe.core.runtime poderão necessitar de adicionar um ou mais dos seguintes plug-ins: