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 Java 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 Código Fonte PDE Não São Efetivadas com Apply
2.18 A Pasta Icons Não É Incluída em
bin.includes de Alguns Gabaritos PDE
2.19 As Ligações de Teclas Emacs Não Funcionam nos 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 Platformdo PDE não são preservadas. Conseqüentemente, elas não são submetidas a operações de Importação/Exportação 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
.
Alterações das cores utilizadas pelo PDE para as páginas de código fonte de seus editores de várias páginas não ficam imediatamente visíveis nos editores abertos depois de pressionar o botão Apply na página Plug-in Development > Editors preference. Uma solução alternativa para esse problema é fechar o editor e abri-lo novamente.
O PDE fornece vários gabaritos que podem ser utilizados para criar projetos e/ou extensões de plug-in completamente funcionais. Quando projetos são criados, o arquivo
build.properties
é criado com o conteúdo inicial, que inclui a propriedade
'bin.includes' que lista o manifesto do plug-in e os JARs do
código. No entanto, ele omite qualquer menção a outros arquivos criados pelo gabarito, como a pasta icons/
. Como pedido, esses arquivos extra não entram no plug-in quando
forem compilados utilizando o arquivo de compilação Ant ou exportados utilizando o assistente 'Export deployable plug-ins and fragments'. Uma solução alternativa para esse problema é adicionar esses arquivos e diretórios manualmente no arquivo build.properties.
As ligações de teclas fora do padrão atualmente não funcionam em campos de páginas que não são do código fonte dos editores de manifesto do PDE.
Retornar para o arquivo Readme principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.