Esta secção descreve as alterações que são necessárias de estiver a tentar alterar o plug-in 2.1 para adoptar o mecanismo e as APIs do 3.0.
O tempo de execução do Eclipse 3.0 é significativamente diferente. A implementação subjacente baseia-se na especificação da estrutura de OSGi. O tempo de execução do Eclipse 3.0 inclui um nível de compatibilidade (no plug-in org.eclipse.core.runtime.compatibility) que mantém as APIs do 2.1. Os programadores de plug-in interessados em mais rendimento e funcionalidade devem considerar adoptar as APIs do 3.0 e remover a sua dependência do nível de compatibilidade. O código de compatibilidade é apresentado em três lugares:
O texto abaixo dá-lhe mais detalhes sobre as classes e métodos que estão presentes por questões de compatibilidade, bem como orientação sobre como actualizar o seu plug-in.
O tempo de execução do Eclipse foi refactorizado em duas partes; gestão de carregamento de classes e de pré-requisitos, bem como gestão de extensão/ponto de extensão. Esta divisão permite a adopção natural/por inteiro da especificação da estrutura de OSGi para gestão de carregamento de classes e de pré-requisitos. Por sua vez, isto vai activar uma quantidade de novas capacidades no tempo de execução do plug-in dinâmico instalar/actualizar/desinstalar para uma configurabilidade de segurança e aumentada.
Enquanto continuamos a abordar os plug-ins, no novo tempo de execução, um plug-in é na verdade um lote mais algumas extensões ou pontos de extensão. O termo lote é definido pela especificação da estrutura de OSGi e remete para uma recolha de tipos e recursos e informação de pré-requisito inter-lote associada. O registo da extensão é o novo formato do registo do plug-in e apenas apresenta em detalhes a informação de extensão e de ponto de extensão. Em geral, a API do registo de extensão é a mesma que a API do registo do plug-in relevante (para obter mais informações, consulte Registos).
No tempo de execução do Eclipse 2.x, o objecto do plug-in tem uma quantidade de funções e responsabilidades:
Na imagem do tempo de execução do Eclipse 3.0, estes papéis e responsabilidades são fabricados em objectos distintos.
Plugin também implementa BundleActivator. Vai reconhecer a conveniência de ter um objecto central a representar o ciclo de vida e a semântica de um plug-in. Repare que esta situação, contudo, não sanciona a inicialização célere de estruturas de dados que são comuns hoje nos plug-ins. Nunca é demais enfatizar que os plug-ins podem ser activados porque uma classe algo periférica foi referenciada durante a verificação de uma classe num qualquer outro plug-in. Ou seja, apenas porque o plug-in foi activado não significa que esta função seja necessária. Repare também que tem a liberdade de definir uma classeBundleActivator diferente ou não ter nenhum activador de lote.
Os passos necessários para a porta de uma classe de 2.x Plugin para o Eclipse 3.0 dependem do que a classe estiver a executar. Como foi abordado anteriormente, a maior parte do trabalho do ciclo de vida de arranque fica numa das seguintes categorias:
No novo tempo de execução existe uma separação entre a informação e as estruturas necessárias para executar um plug-in e os relacionados com as extensões e os pontos de extensão de um plug-in. Isto é definido e gerido pela especificação da estrutura de OSGi. Tratam-se de conceitos específicos do Eclipse e são adicionados pelo código de tempo de execução do Eclipse. Em conformidade, o registo original do plug-in e os objectos relacionados foram divididos em lotes de OSGi e o registo de extensão do Eclipse.
As partes do IPluginRegistry que lidam com a especificação da execução (por exemplo, IPluginDescriptor, ILibrary, IPrequisite) ficaram desactualizadas e as partes remanescentes relacionadas com as extensões e o ponto de extensão foi removido para IExtensionRegistry. Mais ainda, os intitulados objectos do modelo relacionados com o registo do plug-in como um todo tornaram-se agora obsoletos. Estes tipos eram apresentados e instanciados em primeiro lugar pelo tempo de execução para suportar as ferramentas como PDE. Infelizmente, eram frequentes os casos em que o nível de informação necessário ultrapassava as capacidades ou interesses do tempo de execução (por exemplo, lembrar os números de linhas para elementos de plugin.xml) e no final, os consumidores potenciais da informação do tempo de execução tinham de continuar a manter as suas próprias estruturas.
No novo tempo de execução, reavaliámos as funções facultadas pelo tempo de execução e agora faculta apenas as que são essenciais para a execução do tempo de execução ou que são extremamente difíceis de executar por terceiros. Como j+a foi mencionado, os objectos de modelo do registo do plug-in tornaram-se obsoletos tal como a API de identificação do plug-in. O novo registo de extensões mantém as informações essenciais relacionadas com a extensão. Um nova estrutura do estado (consulte org.eclipse.osgi.service.resolver.State e relacionados) representa e permite a manipulação das informações essenciais relacionadas com a execução.
No Eclipse 3.0, a estrutura do fragmento de NL foi actualizada para ser mais consistente. Anteriormente, as conversões de ficheiros como o plugin.properties suponha-se que estavam dentro de JARs facultados por fragmentos. Uma vez que os ficheiros originais estão localizados na raiz do plug-in do sistema central relevante, uma localização mais consistente teria os ficheiros convertidos localizados na raiz dos fragmentos de NL. Por exemplo,
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Repare aqui que o ficheiro nl1.jar anteriormente continha as conversões para plugin.properties. Estes ficheiros estão agora na raiz do fragmento e o JAR contém conversões de quaisquer recursos conversíveis (ou seja, ficheiros carregados através do carregador de classes) no plug-in do sistema central.
Claro que a estrutura do fragmento de NL do Eclipse 2.1 ainda é suportada para plug-ins de sistema central do 2.1 em execução no Eclipse 3.0. Contudo, não pode utilizar um fragmento de NL do 2.1 num plug-in do 3.0. O fragmento tem de ser actualizado para a nova estrutura.
Todo o pacote org.eclipse.core.boot tornou-se obsoleto. BootLoader foi intercalado com org.eclipse.core.runtime.Platform, uma vez que já não fazia sentido ter uma divisão entre o arranque e o tempo de execução. Repare que, na verdade, o plug-in org.eclipse.core.boot foi quebrado e todo o respectivo código foi movido para o novo tempo de execução ou o nível de compatibilidade.
IPlatformConfiguration tem sido sempre um tipo definido por e para o componente Instalar/Actualizar Eclipse. Com a reorganização do tempo de execução podemos redireccionar este tipo para o seu alojamento adequado. Esta classe permanece bastante inalterada e voltou a ser colocado no pacote como org.eclipse.update.configurator.IPlatformConfiguration.
IPlatformRunnable foi movido para org.eclipse.core.runtime.IPlatformRunnable.
O método getDeclaringPlugin()
(em ambas as classes) atribui uma ligação a um nível superior ao plug-in, que declara a extensão ou o ponto de extensão (respectivamente).
O novo modelo de registo separa os aspectos de execução dos plug-ins dos aspectos de extensão/ponto de extensão e já não contém IPluginDescriptors.
Os utilizadores desta API devem considerar o novo método getParentIdentifier() localizado em IExtension e IExtensionPoint.
No tempo de execução original, o registo do plug-in mantinha uma imagem da configuração do tempo de execução. No Eclipse 3.0 esta imagem é dividida pela estrutura de OSGi e do registo da extensão. Desta forma, estas classes ficaram desactualizadas. Os avisos de desactualização contêm detalhes sobre como deve actualizar o seu código.
No novo tempo de execução, os objectos de Plugin já não são geridos pelo tempo de execução e por isso não podem ser acedidos de forma genérica através da Plataforma. De forma semelhante, o registo do plug-in já não existe ou dá acesso aos descritores do plug-in. Contudo, existem métodos de substituição disponíveis e detalhados no Javadoc dos métodos obsoletos nestas classes.
Todos os tipos neste pacote são agora obsoletos. Consulte a discussão em registos para obter mais informações.
Os clientes do método IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) devem revisitar as suas utilizações deste método e considere a utilização do método mais substancial IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). O antigo método IWorkspace.run adquire um bloqueio em todo o espaço de trabalho para a duração do IWorkspaceRunnable. Isto significa que uma operação efectuada com este método nunca será capaz de ser executado em simultâneo com outras operações que estejam a alterar o espaço de trabalho. No Eclipse 3.0, muitas operações de execução longa foram movidas para módulos de segundo plano, por isso a semelhança de conflitos entre as operações é bastante aumentada. Se uma operação de primeiro plano modal for bloqueada por uma operação de segundo plano em execução, a IU fica bloqueada até que a operação de segundo plano termine ou até que uma das operações seja cancelada.
A solução sugerida é comutar todas as referências ao antigo IWorkspace.run para utilizar o novo método com um parâmetro de regras de marcação.
A regra de marcação deve ser a regra mais ajustada que abranja as regras de todas as alterações dessa operação.
Se a operação tentar modificar recursos fora do âmbito da regra de marcação, vai ocorrer uma excepção de tempo de execução.
A regra de marcação precisa exigida por uma determinada operação de espaço de trabalho não é especificada, e pode ser alterada, dependendo do fornecedor do repositório instalado num determinado projecto.
O factory
IResourceRuleFactory
deve ser utilizado para obter a regra de marcação de uma operação de alteração de recursos.
Caso assim o deseje, um MultiRule pode ser utilizado para especificar várias regras de recursos e o método de conveniência MultiRule.combine pode ser utilizado para combinar regras de várias operações de alteração de recursos.
Se não for exigido qualquer bloqueio, pode ser utilizada uma regra de marcação nulo. Isto vai permitir que o executável modifique todos os recursos no espaço de trabalho, mas não irá impedir que outros módulos também modifiquem em simultâneo o espaço de trabalho. Para alterações simples ao espaço de trabalho, é com frequência a solução mais fácil e que melhor proporciona a simultaneidade.
filteredSelection
de selection
:
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
Existe agora a noção explícita de um tipo de anotação. Consulte Annotation.getType() e Annotation.setType(). O tipo de uma anotação pode ser alterado durante o respectivo tempo de vida. Foi adicionado um novo ponto de extensão à declaração de tipos de anotação: "org.eclipse.ui.editors.annotationTypes". Um tipo de anotação tem um nome e pode ser declarado como sendo um subtipo de outro tipo de anotação declarado. Uma declaração de tipo de anotação também pode utilizar os atributos "markerType" e "markerSeverity" para especificar as marcações de um determinado tipo e de uma determinada gravidade que devem ser representados em editores de texto como anotações de um determinado tipo de anotação. Os atributos "markerType" e "markerSeverity" no "org.eclipse.ui.editors.markerAnnotationSpecification" já não devem ser utilizados. As especificações da anotação de marcação estão a ficar independentes das marcações e do nome, levando a engano. Contudo, o nome é mantido para assegurar a retrocompatibilidade.
As instâncias de subclasses de AbstractMarkerAnnotationModel detectam e definem automaticamente os tipos de anotação correcta para anotações que criam de marcações. Para obter de forma programática o tipo de anotação para uma determinada marcação ou um determinado par de markerType e markerSeverity, utilize org.eclipse.ui.texteditor.AnnotationTypeLookup.
O acesso à hierarquia de tipos de anotações é facultado por IAnnotationAccessExtension. Por um determinado tipo de anotação pode obter a cadeia de super tipos e verificar se um tipo de anotação é um subtipo de outro tipo de anotação. DefaultMarkerAnnotationAccess implementa esta interface.
O tipo de anotação é a chave com que vai localizar a especificação da anotação de marcação. Como os tipos de anotações podem expandir outros tipos de anotações, também existe uma relação implícita entre as especificações da anotação da marcação. Deste modo, a especificação da anotação de marcação de um determinado tipo de anotação é completada pelas especificações da anotação de marcação atribuídas aos super tipos do determinado tipo de anotação. Assim, a especificação da anotação de marcação não tem de estar completa porque isto foi exigido antes. As especificações da anotação de marcação são obtidas por AnnotationPreferences. Ao utilizar org.eclipse.ui.texteditor.AnnotationPreferenceLookup, pode obter uma preferência de anotação para um determinado tipo de anotação que executa de forma transparente a conclusão da preferência juntamente com a cadeia de super tipo de anotação.
A especificação da anotação de marcação foi expandida com três atributos adicionais para permitir a definição de aparências personalizadas de um determinado tipo de anotação no regulador vertical. Estes atributos são: "icon", "symbolicIcon", e "annotationImageProvider". O valor de "icon" é o caminho para um ficheiro que contém a imagem do ícone. O valor de "symbolicIcon" pode ser de "erro", "aviso", "info", "tarefa", "marcador". O atributo "symbolicIcon" é utilizado para informar a plataforma que a anotação deve ser representada com as mesmas imagens que são utilizadas pelas plataforma para apresentar erros, avisos, infos, tarefas e marcadores, respectivamente. O valor de "annotationImageProvider" é uma classe a implementar org.eclipse.ui.texteditor.IAnnotationImageProvider, que permite uma apresentação da anotação personalizada total.
O regulador vertical utiliza o IAnnotationAccess/IAnnotationAccessExtension associado para desenhar anotações. O regulador vertical já não chama Annotation.paint. Em geral, já não é suposto as Anotações desenharem-se a si próprias. Os métodos "paint" e "getLayer" tornaram-se obsoletos para eventualmente tornar a anotação independente da IU. DefaultMarkerAnnotationAccess serve como implementação predefinida de IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementa a seguinte estratégia para pintar anotações: Se uma anotação implementar IAnnotationPresentation, IAnnotationPresentation.paint é chamado. Caso contrário, o fornecedor da imagem de anotação é procurado na preferência da anotação. O fornecedor da imagem de anotação só está disponível se for especificado e se o plug-in que define a especificação da anotação de marcação delimitadora já tiver sido carregada. Caso exista um fornecedor de imagem de anotação, a chamada é enviada para ele. Caso contrário, o "ícone" especificado é procurado. "symbolicIcon" é utilizado como o retrocesso final. Para anotações de desenho, o nível de apresentação da anotação é relevante. DefaultMarkerAnnotationAccess procura o nível de apresentação utilizando a seguinte estratégia: Se a preferência da anotação especificar um nível de apresentação, é utilizado o nível especificado. Caso não exista qualquer nível e a anotação implementar IAnnotationPresentation, IAnnotationPresentation.getLayer é utilizado, senão o nível de apresentação predefinido (que é 0) é devolvido.
São declarados os seguintes tipos de anotação pelo plug-in org.eclipse.ui.editors:
<extension point="org.eclipse.ui.editors.annotationTypes"> <type name="org.eclipse.ui.workbench.texteditor.error" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="2"> </type> <type name="org.eclipse.ui.workbench.texteditor.warning" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="1"> </type> <type name="org.eclipse.ui.workbench.texteditor.info" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="0"> </type> <type name="org.eclipse.ui.workbench.texteditor.task" markerType="org.eclipse.core.resources.taskmarker"> </type> <type name="org.eclipse.ui.workbench.texteditor.bookmark" markerType="org.eclipse.core.resources.bookmark"> </type> </extension>
A extensão markerAnnotationSpecification definida já não faculta atributos "markerType" e "markerSeverity". Definem o atributo "symbolicIcon" com o valor em conformidade. Desta forma, MarkerAnnotation.paint e MarkerAnnotation.getLayer já não são chamados, ou seja, a sobreposição destes métodos não tem qualquer efeito. Os clientes afectados devem implementar IAnnotationPresentation.
Com a introdução dos modos de lançamento extensíveis no 3.0, mais do que um delegado de lançamento pode existir para um tipo de configuração de lançamento.
As edições anteriores à 3.0 apenas suportavam um delegado de lançamento por tipo de configuração de lançamento.
O método ILaunchConfigurationType.getDelegate()
é agora obsoleto.
O método getDelegate(String mode)
deve ser utilizado no respectivo lugar para obter o delegado de lançamento para um modo de lançamento específico.
O método obsoleto foi alterado para devolver o delegado de lançamento para o modo run
.
Os grupos de separadores de lançamento e os separadores de lançamento já não são notificados quando terminar um lançamento.
O método launched(ILaunch)
nas interfaces ILaunchConfigurationTab
e
ILaunchConfigurationTabGroup
tornou-se obsoleto e já não é chamado.
Depender deste método para a função de lançamento sempre foi problemático, uma vez que os separadores apenas existem quando o lançamento é executado no diálogo de lançamento.
Além disso, com a introdução do lançamento de segundo plano, este método já não pode ser chamado, visto que o diálogo de lançamento vai fechar-se antes de existir o objecto de lançamento resultante.
Foram adicionados dois métodos à interface ILaunchConfigurationTab
- activada e desactivada. Estes novos métodos do ciclo de vida são chamados quando um separador for inserido e quando sair dele, respectivamente.
As implementação existentes de ILaunchConfigurationTab
, que colocam na subclasse a classe abstracta facultada pelo plug-in de depuração (AbstractLaunchConfigurationTab
),
são compatíveis com binário, uma vez que os métodos são implementados na classe abstracta.
Em edições anteriores, era enviada a mensagem initializeFrom
ao separador quando estava activado e performApply
quando estava desactivado. Desta forma, a estrutura do separador de configuração de lançamento facultava comunicação inter-separadores através de uma configuração de lançamento (actualizando a configuração com os valores de atributo actual quando se sai de um separador, e actualizando o separador recém-inserido). Contudo, uma vez que muitos separadores não executam comunicação inter-separadores, esta acção pode ser ineficaz.
Da mesma forma, não havia um meio para distinguir entre um separador que está a ser activado e um separador que apresenta uma configuração de lançamento seleccionado pela primeira vez.
Os métodos recém-adicionados permitem que os separadores distingam entre a activação e a inicialização, e a desactivação e a salvaguarda de valores actuais.
A implementação predefinida de activated
, facultada pelo separador abstracto, chama initializeFrom
. Além disso, a implementação predefinida de deactivated
chamaperformApply
. Os separadores que quiserem tirar partido da nova API devem sobrepor estes métodos como solicitado.
Geralmente, para separadores que não executem comunicação inter-separadores, a abordagem recomendada é voltar a implementar estes métodos para não tomarem qualquer acção.
Em edições anteriores, a comutação de perspectiva era especificada numa configuração de lançamento, através dos atributos de configuração de lançamento ATTR_TARGET_DEBUG_PERSPECTIVE
e ATTR_TARGET_RUN_PERSPECTIVE
. Com a adição dos modos de lançamento extensíveis no 3.0, esta abordagem já não é escalonada. A comutação de perspectivas é agora especificada numa base de tipo de configuração de lançamento, por modo de lançamento que um tipo de configuração de lançamento suportar.
Foi adicionada a API a DebugUITools
para definir e obter a perspectiva associada a um tipo de configuração de lançamento para um modo de lançamento específico.
Foi adicionado um elemento adicional e opcional, launchMode
, ao ponto de extensão launchConfigurationTabGroup
, permitindo que um grupo de separadores contribuído especificasse uma perspectiva predefinida para um tipo e modo de configuração de lançamento.
Na interface de utilizador do Eclipse, os utilizadores podem editar a perspectiva associada a um tipo de configuração de lançamento abrindo o diálogo da configuração de lançamento e seleccionando um nó de tipo de configuração de lançamento na árvore (em vez de uma configuração individual). É apresentado um separador a permitir que o utilizador defina uma perspectiva com cada modo de lançamento suportado.
Foram adicionados dois métodos à classe VMRunnerConfiguration
para suportar a definição e obtenção de variáveis de ambiente.
Os implementadores de IVMRunner
devem chamar
VMRunnerConfiguration.getEnvironment()
e transmitir esse ambiente para a JVM executada. Os clientes que utilizemDebugPlugin.exec(String[]
cmdLine, File workingDirectory)
podem executar esta acção chamando em vez disso DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
. Basta transmitir o resultado de getEnvironment()
.
Em edições anteriores, o VMRunnerConfiguration
tinha um atributo para descrever um caminho de início.
O atributo é uma recolha de Strings
para ser especificada no argumento -Xbootclasspath
. Foram adicionados três novos atributos a VMRunnerConfiguration para suportar JVMs que permitem anexar previamente e anexar ao caminho de início.
Os novos métodos/atributos adicionados são:
getPrependBootClassPath()
- devolve uma recolha de entradas para serem anexadas previamente ao caminho de início (o argumento -Xbootclasspath/p
)getMainBootClassPath()
- devolve uma recolha de entradas para serem colocadas no caminho de início (o argumento-Xbootclasspath
)getAppendBootClassPath()
- devolve uma recolha de entradas para serem anexadas ao caminho de início (o argumento-Xbootclasspath/a
)O antigo atributo, getBootClassPath()
, ainda existe e contém um caminho completo equivalente ao dos três novos atributos. Contudo, VMRunners
que suporta as novas opções do caminho de início deve tirar partido dos novos atributos.
A função de cópia de trabalho do modelo Java foi retrabalhada no 3.0 para facultar uma funcionalidade bastante mais melhorada. Antes do 3.0, o modelo Java permitia a criação de cópias de trabalho individuais de unidades de compilação. As alterações podiam ser efectuadas na cópia de trabalho e consolidadas mais tarde. Existia suporte para uma análise limitada de uma cópia de trabalho no contexto do restante do modelo Java. Contudo, não havia forma destas análises entrarem em linha de conta com mais do que uma das cópias de trabalho de cada vez.
As alterações no 3.0 tornaram possível criar e gerir conjuntos de cópias de trabalho de unidades de compilação, bem como executar análises na presença de todas as cópias de trabalho num conjunto. Por exemplo, agora é possível para um cliente como a refactorização de JDT criar cópias de trabalho para uma ou mais unidades de compilação que estiver a considerar modificar e depois processar referências de tipo entre as cópias de trabalho. Antigamente, isto só era possível depois das alterações às cópias de trabalho da unidade de compilação terem sido consolidadas.
A API de modelo Java é alterada de 2 formas para adicionar este suporte melhorado:
(1) A funcionalidade anteriormente encontrada em IWorkingCopy
e herdada por ICompilationUnit
foi consolidada para ICompilationUnit
.
A interface IWorkingCopy
só era utilizada neste local e era mais geral do que necessitava de ser.
Esta alteração simplifica a API. IWorkingCopy
ficou desactualizada.
Outros locais na API em queIWorkingCopy
é utilizado como parâmetro
ou tipo de resultado também se tornaram obsoletos; os métodos da API de
substituição mencionam ICompilationUnit
em vez
deIWorkingCopy
.
(2) A interface IBufferFactory
foi substituída porWorkingCopyOwner
.
O suporte melhorado para cópias de trabalho exige que exista um objecto que seja proprietário das cópias de trabalho.
Apesar de IBufferFactory
estar no local correcto, o nome não transmite adequadamente como funciona o novo mecanismo da cópia de trabalhos.
WorkingCopyOwner
é muito mais sugestivo.
Além disso, WorkingCopyOwner
é declarado como uma classe abstracta, em vez de como uma interface, para permitir que a noção do proprietário da cópia de trabalhos evolua no futuro.
O único método em IBufferFactory
move-se sem alteração para WorkingCopyOwner
. WorkingCopyOwner
não implementa IBufferFactory
para clarificar que IBufferFactory
é coisa do passado.
IBufferFactory
tornou-se obsoleto. Outros locais na API, onde
IBufferFactory
surge como um parâmetro ou tipo de resultado também
se tornou obsoleto; os métodos da API de substituição mencionam
WorkingCopyOwner
em vez de IBufferFactory
.
Estas alterações não quebram a compatibilidade binária.
Ao migrar, todas as referências ao tipo IWorkingCopy
devem, em vez disso, referenciar ICompilationUnit
. A única implementação de IWorkingCopy
implementa também ICompilationUnit
, o que significa que os objectos de tipo IWorkingCopy
podem ser difundidos em segurança para
ICompilationUnit
.
Uma classe que implemente IBufferFactory
vai ter de ser substituída por uma subclasse de WorkingCopyOwner
. Apesar de WorkingCopyOwner
não implementar em si IBufferFactory
, seria possível declarar a subclasse de WorkingCopyOwner
que implemente IBufferFactory
, criando assim uma ponte entre o antigo e o novo (IBufferFactory
declara createBuffer(IOpenable)
em que WorkingCopyOwner
declara createBuffer(ICompilationUnit)
; ICompilationUnit
expande IOpenable
).
Devido às alterações que envolvemIWorkingCopy
e IBufferFactory
estarem interligadas, recomenda-se que processe ambos ao mesmo tempo.
Os detalhes das desactualizações são os seguintes:
IWorkingCopy
(pacote org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
tornou-se obsoleto.
ICompilationUnit
:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
como ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
public void destroy()
tornou-se obsoleto.
ICompilationUnit
:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
como ((ICompilationUnit)
wc).discardWorkingCopy()
public IJavaElement
findSharedWorkingCopy(IBufferFactory)
tornou-se obsoleto.
ICompilationUnit
:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
substitui IBufferFactory.
public IJavaElement getOriginal(IJavaElement)
tornou-se obsoleto.
IJavaElement
:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
como elt.getPrimaryElement()
IWorkingCopy.getOriginal
, IJavaElement.getPrimaryElement
não devolve nulo
se o receptor não for uma cópia de trabalhos.
public IJavaElement getOriginalElement()
tornou-se obsoleto.
ICompilationUnit
:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
como((ICompilationUnit)
wc).getPrimary()
IWorkingCopy.getOriginalElement
, IWorkingCopy.getPrimary
não devolve nulo
se o receptor não for uma cópia de trabalhos.
public IJavaElement[] findElements(IJavaElement)
tornou-se obsoleto.
ICompilationUnit
.
wc.findElements(elts)
como ((ICompilationUnit)
wc).findElements(elts)
public IType findPrimaryType()
tornou-se obsoleto.
ICompilationUnit
.
wc.findPrimaryType()
como ((ICompilationUnit)
wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
tornou-se obsoleto.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
substitui IBufferFactory.
public IJavaElement getWorkingCopy()
tornou-se obsoleto.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
como((ICompilationUnit)
wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
tornou-se obsoleto.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
substitui IBufferFactory.
public boolean isBasedOn(IResource)
tornou-se obsoleto.
ICompilationUnit
:
public boolean hasResourceChanged()
wc.isBasesOn(res)
como ((ICompilationUnit)
wc).hasResourceChanged()
public boolean isWorkingCopy()
tornou-se obsoleto.
ICompilationUnit
.
wc.isWorkingCopy()
como ((ICompilationUnit)
wc).isWorkingCopy()
public IMarker[] reconcile()
tornou-se obsoleto.
ICompilationUnit
:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
como ((ICompilationUnit)
wc).reconcile(false, null)
nulo
; o método de substituição não devolve um resultado.
public void reconcile(boolean, IProgressMonitor)
tornou-se obsoleto.
ICompilationUnit
.
wc.reconcile(b,monitor)
como ((ICompilationUnit)
wc).reconcile(b.monitor)
public void restore()
tornou-se obsoleto.
ICompilationUnit
.
wc.restore()
como ((ICompilationUnit)
wc).restore()
IType
(pacote org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
tornou-se obsoleto.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
para ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
tornou-se obsoleto.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
para ICompilationUnit[]
.IClassFile
(pacote org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
tornou-se obsoleto.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
substitui IBufferFactory.
JavaCore
(pacote org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
tornou-se obsoleto.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
substitui IBufferFactory.
ICompilationUnit[]
para IWorkingCopy[]
.SearchEngine
(pacote org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
tornou-se obsoleto.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
para ICompilationUnit[]
.O plug-in org.eclipse.help, que mantinha as APIs e os pontos de extensão para contribuir e expandir o sistema de ajuda, bem como apresentar a ajuda, contém agora apenas APIs e pontos de extensão para contribuir e aceder a recursos de ajuda. Uma parte da implementação da IU de ajuda predefinida contida nesse plug-in foi movida para um novo plug-in org.eclipse.help.base, juntamente com as APIs para expandir a implementação. As APIs e o ponto de extensão para contribuir IU de Ajuda e apresentar ajuda foram movidos para o plug-in org.eclipse.ui. Esta reestruturação permite que as aplicações tenham uma maior flexibilidade em relação ao sistema de ajuda; a nova estrutura permite que as aplicações baseadas na área de trabalho genérica facultem a sua IU de Ajuda e/ou implementação de Ajuda ou que omitam totalmente o sistema de ajuda.
Visto que os pontos de extensão e os pacotes da API afectados se destinam apenas a utilização por parte do próprio sistema de ajuda, não é provável que os plug-ins existentes sejam afectados por esta alteração. Estão aqui incluídos apenas por questões globais:
Foi adicionada uma nova API para implementar as pesquisas personalizadas no 3.0. A API original ficou desactualizada no 3.0 e recomenda-se que os clientes aportem na nova API nos pacotes org.eclipse.search.ui e org.eclipse.search.ui.text.
Os clientes terão de criar as implementações deISearchQuery
, ISearchResult
e ISearchResultPage
. A implementação deISearchResultPage
tem de ser contribuída para o novo ponto de extensão org.eclipse.search.searchResultViewPages
.
As implementações predefinidas paraISearchResult
e ISearchResultPage
são facultadas no pacote
org.eclipse.search.ui.text
.
Antes do 3.0, se chamasse DirectoryDialog.setMessage(String string) ou MessageBox.setMessage(String string) de SWT com um valor nulo para cadeia, iria resultar num diálogo sem texto no título. Este comportamento não foi especificado (transmitir nulo nunca foi permitido) e cria problemas com getMessage que não tem permissão para devolver nulo. No 3.0, a transmissão de nulo resulta agora no lançamento de uma excepção IllegalArgumentException e as especificações foram alteradas para indicar esta situação, trazendo-a para a linha da frente com o método na respectiva superclasse Dialog.setMessage. Se utilizar Dialog.setMessage, certifique-se de que a cadeia transmitida nunca é nula. Transmita apenas uma cadeia vazia se quiser um diálogo sem texto no título.
O suporte de operações simultâneas exige formas mais sofisticadas de mostrar progresso modal. Como parte do progresso adicional de esforço de resposta, foi implementado suporte na classe IProgressService. A forma existente de mostrar progresso com o ProgressMonitorDialog ainda está a funcionar. Contudo, para melhorar a experiência do utilizador recomenda-se a migração para o novo IProgressService.
O documento Showing Modal Progress in Eclipse 3.0 descreve como deve migrar para o novo IProgressService.
O ponto de extensão Grupos de Acção de Depuração (org.eclipse.debug.ui.debugActionGroups) foi removido. No Eclipse 3.0, a área de trabalho introduziu suporte para Actividades através do ponto de extensão org.eclipse.platform.ui.activities. Este suporte faculta tudo o que os Grupos de Acção de Depuração facultavam, sendo de mais fácil utilização (suporta padrões em vez de especificar todas as acções exaustivamente) e tem uma API programática para o suportar. Se falhar a remoção de referências para o antigo ponto de extensão, não vai originar quaisquer falhas. As referências ao ponto de extensão vão simplesmente ser ignoradas. Os fornecedores do produto são encorajados a utilizar o suporte de Actividades da área de trabalho para associar acções de depurador específicas da linguagem a actividades específicas da linguagem (por exemplo, acções de depuração C++ podem ser associadas a uma actividade denominada "Programar C++").
IBreakpointManager define agora os métodos setEnabled(boolean) e isEnabled(). Quando o gestor de ponto de interrupção estiver desactivado, os depuradores devem ignorar todos os pontos de interrupção registados. A plataforma de depuração também faculta um novo mecanismo de receptor, IBreakpointManagerListener, que permite aos clientes registarem-se com o gestor de ponto de interrupção para serem notificados quando for alterada a sua activação. A vista Pontos de interrupção chama esta API de uma nova acção de comutação que permite ao utilizador "Ignorar todos os pontos de interrupção." Os depuradores que não respeitem a activação do gestor do ponto de interrupção irão surgir quebrados se o utilizador tentar utilizar esta função.
As linguagens próximas Java (como JSP, SQLJ, JWS, etc.) devem poder participar na pesquisa Java. Em particular, os implementadores dessas linguagens devem ser capazes de:
Um implementador deste tipo denomina-se participante da pesquisa. Vai expandir a classe SearchParticipant. Os participantes da pesquisa são transmitidos para consultas de pesquisa (consulte SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
Para indexar ou localizar correspondências, um participante da pesquisa tem de definir uma subclasse de SearchDocument que pode obter o conteúdo do documento, através da sobreposição de getByteContents() ou de getCharContents(). É devolvida uma instância desta subclasse em getDocument(String).
Um participante da pesquisa que quiser indexar algum documento irá utilizar SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) para agendar a indexação do documento determinado no índice determinado. Uma vez que o documento esteja pronto para ser indexado, a estrutura subjacente chama SearchParticipant.indexDocument(SearchDocument, IPath). O participante da pesquisa obtém depois o conteúdo do documento, identifica-o e adiciona as entradas do índice utilizando SearchDocument.addIndexEntry(char[], char[]).
Uma vez realizada a indexação, pode-se depois consultar os índices e localizar as correspondências, utilizando SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Primeiro vai solicitar a cada participante da pesquisa os índices necessários para esta consulta utilizando SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). Para cada entrada do índice que corresponda ao padrão determinado, é criado um documento da pesquisa solicitado ao participante da pesquisa (consulte getDocument(String)). Todos estes documentos são transmitidos para o participante da pesquisa para que possa localizar as correspondências, utilizando locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). O participante da pesquisa notifica o SearchRequestor das correspondências da pesquisa, utilizando acceptSearchMatch(SearchMatch) e transmitindo uma instância de uma subclasse de SearchMatch.
Um participante da pesquisa pode delegar parte do seu trabalho ao participante da pesquisa Java predefinido. Uma instância deste participante predefinido é obtida utilizando SearchEngine.getDefaultSearchParticipant(). Por exemplo, quando solicitado que localize as correspondências, um participante de SQLJ pode criar documentos .java dos documentos .sqlj e delegar o trabalho para o participante predefinido que o transmitir para os documentos .java.