1.0 Introdução
2.0 Problemas e Limitações Conhecidos
2.1 Comentários em Páginas de Origem de Editores XML do PDE
2.2 Operações da Área de Transferência na Exibição de Propriedades
2.3 Problema ao Importar Fragmentos
2.4 Suposição de que a Saída Esteja na Pasta bin/
2.5 Preferências Não Funcionando com a Importação/Exportação
2.6
Operações da Área de Transferência Não Funcionam no Editor Feature Manifest
2.7
A Escolha de Calcular Caminho de Construção Faz com que o Projeto JavaTM Não Seja Mais Construído
2.8
ECLIPSE_HOME Produz Caminhos de Classe Frágeis Devido aos Números de Versão nos Caminhos de
Diretórios de Plug-in
2.9
O Assistente Plug-in Import Não Permite que Plug-ins de Diferentes Versões Sejam
Importados
2.10 Tipo do PDE Requerido para a Verificação da Sintaxe do Manifesto de Plug-in
2.11 O PDE Não Preserva o Layout do Arquivo de Manifesto Original
2.12
Ir para a Linha no Editor de Manifesto Faz com que a Exibição Outline Fique em Branco
2.13
O Assistente New Feature Não Gera o Arquivo build.properties
2.14
Atualizar Classpath Anexa a Origem a partir da Instalação Incorreta
2.15 Não Há como Especificar o Tipo de Biblioteca do Plug-in
2.16
As Bibliotecas de Tempo de Execução Exportadas Através de Mais de 2 Plug-ins Não Estão no Classpath
2.17 As Cores da Página de
Origem PDE Não São Efetivadas ao Aplicar
2.18 Pasta de
Ícones Não Incluída em bin.includes de Alguns Gabaritos PDE
2.19 Ligações de Chave
Emacs Não Funcionam em Campos do Editor de Manifesto
Este tópico contém informações sobre problemas e limitações conhecidos no Plug-in Development Environment.
O PDE fornece uma série de editores de várias páginas que incluem uma página de origem bruta. Os editores que tratam de arquivos XML (manifestos de plug-in, fragmento e recurso) preservarão os comentários na maioria dos casos. No entanto, os comentários não serão preservados se incluídos antes do elemento XML raiz ou se incluídos após o último elemento filho contido no elemento pai.
Os atalhos da área de transferência (Ctrl+X, Ctrl+C, Ctrl+V etc.) não funcionam em editores de célula de propriedades que pertencem ao PDE Plug-in Manifest Editor. Utilize o menu pop-up para ativar essas operações.
Se uma área de trabalho tiver projetos binários para um plug-in e um fragmento que faz referência a esse plug-in, as bibliotecas de fragmentos serão incluídas no caminho da classe do objeto plug-in referenciado. Quando é feita uma tentativa de sobrescrever o plug-in e o fragmento com versões de uma outra construção, a exclusão do fragmento antigo pode falhar. Se isso ocorrer, repita a operação para corrigir a área de trabalho. Apenas o plug-in e o fragmento afetados precisam ser reimportados.
O PDE assume que todos os projetos de plug-in e de fragmento que contêm código Java possuem uma ou mais pastas de origem e saída de construção na pasta bin/. Embora seja possível alterar o nome da pasta de saída no diálogo Properties, o launcher do workbench de tempo de execução do PDE não funcionará corretamente se você fizer isso.
As preferências definidas na página de preferências Target Platform do PDE não são preservadas. Conseqüentemente, elas não são submetidas a operações Import/Export no diálogo Preferences.
As páginas de GUI do Editor Feature Manifest suportam menus pop-up que contêm operações padrão da área de transferência (como recortar, copiar e colar). No entanto, nenhuma dessas operações funciona para widgets estruturais (árvores e listas). O único local no qual essas operações funcionam é nos widgets de texto nas páginas Information e Source.
O PDE calcula o caminho da classe de construção de um projeto de plug-in consultando
mapeamentos de origem no arquivo build.properties
. Esse arquivo define como as pastas de
origem são compiladas em bibliotecas de tempo de execução. Na falta desse arquivo, o PDE
calculará o caminho da classe que não contém pastas de origem, resultando em
erros de compilação. O arquivo build.properties
requerido é gerado
pelo PDE quando um novo projeto de plug-in é criado. Se o projeto de plug-in for criado
de algum outro modo, um arquivo build.properties
deverá ser incluído
manualmente.
Consulte o Guia do PDE para obter detalhes sobre o formato dos arquivos
build.properties
.
Os produtos Eclipse são geralmente construídos de modo que os plug-ins estejam localizados no mesmo
diretório e cada plug-in esteja no diretório cujo nome inclua um
ID de plug-in e um ID de versão (por exemplo, "org.eclipse.ui_2.0.0
").
Se forem utilizados plug-ins externos durante a auto-hospedagem, esses nomes de diretórios de plug-in
serão mostrados nos caminhos de classes gerados pelo PDE. Esses caminhos de classes são sensitivos em relação a alterações de versão de plug-in e devem ser recalculados se a plataforma de destino utilizar números de
versão diferentes.
O WebSphere Studio permite a coexistência de dois plug-ins com o mesmo ID, porém com versões diferentes, caso eles colaborem apenas com bibliotecas de tempo de execução. No entanto, o PDE não pode tratar desses plug-ins porque ele cria nomes de projetos utilizando IDs de plug-in durante a importação de projetos binários.
O PDE só poderá fornecer verificação de sintaxe e marcadores de erro/aviso para manifestos de plug-in se o projeto de plug-in tiver o tipo do plug-in do PDE. Um projeto de plug-in obtém automaticamente esse tipo quando criado por um assistente do PDE. Essa situação só poderá ocorrer se um projeto Java regular tiver sido utilizado para hospedar um plug-in. O problema pode ser corrigido convertendo-o em um projeto do PDE.
Quando uma página não-Source de um editor de manifesto do PDE é utilizada, o PDE converte as alterações de volta para XML, gerando novamente o arquivo. Embora o conteúdo global e os comentários sejam preservados, o mesmo não ocorre com o layout do arquivo real. Isso pode causar problemas, mostrando alterações falsas durante a comparação de arquivos. Se o layout do arquivo for importante, execute toda a edição na página Source. Alternativamente, evite utilizar páginas Source juntas. Como os arquivos XML são gerados de um modo que respeita e preserva a ordem relativa dos principais elementos (extensões, portas de extensão etc.), as alterações feitas em uma página não-Source de um editor de manifesto do PDE não resultam em deltas falsos durante a comparação de arquivos.
Quando o comando Source > Go To Line é chamado na página Source de um editor de manifesto do PDE, a exibição Outline torna-se cinza. Como a página Source não possui um contorno funcional, não há perda real da função.
Durante a criação de um novo projeto de recurso, o assistente do PDE não gera
automaticamente um arquivo build.properties
. Como resultado, construir o recurso
cria um JAR de recurso sem qualquer conteúdo. Como solução alternativa, crie um build.properties
manualmente, utilizando as instruções fornecidas no Guia do PDE.
As bibliotecas Java são associadas ao código fonte de acordo com as localizações de código fonte especificadas em uma preferência do PDE. Por padrão, essas localizações são registradas por plug-ins da instância do WebSphere Studio de tempo de design. Se a plataforma de destino não for a mesma que a da instância de design, o código fonte fornecido por esses plug-ins não será sincronizado com as bibliotecas. A solução alternativa é desmarcar as localizações padrão e definir novas localizações de código fonte que apontem para os plug-ins suportados pela origem na instalação de destino do WebSphere Studio.
Os editores de manifesto do PDE não fornecem widgets para especificar tipos de bibliotecas de tempo de execução como "code" ou "resource". A única forma de especificar esse atributo é incluí-lo manualmente na página de origem.
Se um plug-in precisar de uma biblioteca de tempo de execução exportada através de mais de
dois plug-ins, ele não será incluído automaticamente no caminho da classe de compilação quando
gerar o arquivo build.xml
. Exemplo: O plug-in A exporta suas
bibliotecas, o plug-in B requer o plug-in A e o reexporta, o plug-in C requer
o plug-in B e o reexporta. Se o plug-in D precisar do plug-in C, quando gerar o
arquivo build.xml
, as bibliotecas do plug-in A não serão incluídas no
caminho de compilação mesmo que elas estejam disponíveis no tempo de execução. O problema pode ser
solucionado da seguinte forma:
- Gere um
build.xml
utilizando o PDE (selecione o arquivoplugin.xml
e clique em Create Plug-in JARs)- Edite o
build.properties
e inclua a seguinte linha:
custom = true- Inclua os JARs ausentes no classpath da tarefa javac no
build.xml
.
As alterações às cores que o PDE utiliza para páginas de origem de seus editores multi-páginas não são visíveis imediatamente em editores abertos depois de pressionar o botão Apply na página Plug-in Development > Editors preference. Para solucionar este problema, feche o editor e abra-o novamente.
O PDE fornece vários gabaritos que podem ser utilizados para criar
projetos e/ou extensões de plug-in inteiramente funcionais. Quando os
projetos são criados, o arquivo build.properties
é
criado com o conteúdo inicial, o qual inclui a propriedade
'bin.includes' listando o manifesto do plug-in e seus JARs de código.
Contudo, ele omite menção a outros arquivos criados pelo gabarito,
tais como a pasta icons/
. Como um pedido, esses arquivos
extras não terminam no plug-in quando construído utilizando um
arquivo de construção Ant ou exportado utilizando o assistente
'Export deployable plug-ins and fragments'. Para solucionar este
problema, adicione esses arquivos e diretórios manualmente no arquivo
build.properties.
Ligações de chave não padrão atualmente não funcionam em campos em páginas não de origem dos editores de manifesto do PDE.
Retornar para o arquivo leia-me principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.