O link ausente, entendendo o problema

Quantas vezes seu plug-in ou recurso personalizado do Eclipse falhou após a exportação para outro aplicativo com base no Eclipse?

Encontrar e satisfazer a todas as suas dependências de plug-in no novo ambiente está mais simples. No passado, era necessário realizar validação manual de plug-ins, mas hoje, a ferramenta de visualização de dependência do Eclipse, parte do projeto Eclipse Incubator, removes ou reduz essa necessidade. Vamos explorar o problema detalhadamente, procurar as soluções disponíveis e considerar possíveis modificações para facilitar as tarefas de análise de dependência de plug-in.

OSGi, o boom

Eclipse mudou a forma como Java™ e programadores em outra linguagem desenvolvem os aplicativos, além de ter facilitado a criação de aplicativos de grande porte, "tijolo por tijolo". Embora não seja um conceito novo, ter todas as dependências definidas claramente em pacotes concisos é uma benção para muitos desenvolvedores.

O advento do Open Services Gateway Initiative (OSGi), e de seu belo mecanismo de atualização de aplicativos substituindo/adicionando/excluindo pacotes, criou novas possibilidades. Atualmente, atualização de aplicativos baseados no Eclipse em computadores cliente é tão simples e comum quanto atualizar aplicativos com base na Web.

O problema

Devemos lembrar que para todo o mecanismo de atualização funcionar apropriadamente, há muito trabalho a ser feito em segundo plano. Sabemos que qualquer aplicativo com base em Eclipse pode ser atualizado simplesmente soltando os pacotes nas pastas apropriadas, mas e com relação às dependências? Quantas vezes você perdeu uma funcionalidade ou recebeu o temido erro de carregamento do Eclipse, sem nenhuma dica do que aconteceu?

O problema pode estar em dois cenários:

• Instalação de recursos de terceiros— As chances de ocorrer a perda de dependências são reduzidas. No melhor cenário possível, elas são tratadas antes do release, mas nós sabemos que esse nem sempre é o caso.
• Criação de um recurso— O Eclipse fornece diversas APIs e muitos programadores deixam de usar a plataforma de destino. Ao exportar os pacotes, a instalação do Eclipse falha.

O culpado é a falha em identificar e documentar o conjunto mínimo de pacotes, chamado daqui pra frente de dependências, para o novo recurso.

Enfrentamos esse cenário recentemente, enquanto planejávamos usar a ferramenta de testes SWTBot em um de nossos projetos. Assim como em outras ferramentas de teste de automação, uma parte do SWTBot deve ficar no aplicativo a ser testado (AUT) para que a automação funcione. Se o recurso SWTBot for instalado em um aplicativo usando o recurso de atualização Equinox P2, ele cuidará das dependências. Muitas vezes, no entanto, isso não é possível, por exemplo, quando o aplicativo não está ativado para P2.

Nada a temer (ainda); vamos para a próxima seção.

A solução (não tão boa)

Podemos resolver esse problema de forma plausível de diversas maneiras:

1. <Application Executable> -clean -console

   
   inicie o console OSGi enquanto inicia o aplicativo
2. Procure um por um os plug-ins não resolvidos em busca de suas dependências

Se você tiver sorte, receberá uma mensagem de erro simples como "Could not resolve bundle ABC due to missing required bundle XYZ."

Caso contrário, verá "Could not resolve bundle ABC due to missing package XYZ" , pois você precisa identificar qual pacote exporta o pacote especificado.

Não é possível usar o comando package<package name> para localizar o pacote, pois ele funcionará somente quando o pacote em questão for resolvido. Se tivesse resolvido, você não teria recebido o erro.

Há uma dimensão não favorável adicionada à abordagem do console. Considere uma situação na qual as coisas funcionam bem em seu lado, mas não em um computador remoto onde os usuários não são técnicos o suficiente para usar o console. Mesmo se você tiver um usuário experiente, você não deseja vê-lo coçando a cabeça, se questionando sobre as habilidades do desenvolvedor.

Por fim, aplicativos com base em Eclipse normalmente usam um mecanismo personalizado para começar, por exemplo, um script personalizado quando não é possível fornecer a opção -console diretamente.

Com isso em mente, vamos analisar uma solução melhor.

Uma solução melhor

O trabalho em segundo plano mencionado anteriormente não precisa ser sempre difícil. Melhor trabalharmos de forma inteligente e o Eclipse Project nos ajuda a fazer isso.

Este artigo demonstra o uso da ferramenta do Eclipse Project de Visualização de dependência, que exibe as dependências de plug-ins sem iniciar o aplicativo de destino. Isso ajuda a identificar os plug-ins não resolvidos antes de o aplicativo ser lançado.

Voltar para parte superior

Projeto Eclipse PDE – Visualização de dependência

Observação: o plug-in Visualização de dependência para mostrar o gráfico de dependências funciona com o Eclipse versão 3.5.X ou mais recente.

Configuração e uso

1. Instale o recurso usando o recurso de repositório de atualizações do Eclipse. Vá até Help>Install New Software e cole em http://download.eclipse.org/eclipse/pde/incubator/visualization/site. Desmarque a caixa de seleção Group items by category .

   Em seguida, vá até Window>Show View>Other>Graph Plug-in Dependencies view, ou pressione Ctrl+3 e selecione Graph Plug-in Dependencies view como na Figura 1.

   
   
   Figura 1. Visão em gráfico das dependências do plug-in
   
   
   
2. Vá até Window>Preferences>Plug-in Development>Target Platform e aponte para a plataforma de destino do Eclipse para incluir os plug-ins de <application_install>/dropins e <application_install>/plugins e defina como ativo. Clique em Apply.(Consulte a Figura 2.)
   
   Figura 2.
   
   
   
3. Clique com o botão direito do mouse e selecione Focus On. Selecione o plug-in sob os drop-ins dos quais você deseja ver o gráfico de dependência. Aqui org.eclipse.emf.core

   Três ferramentas de análise de dependência foram adicionadas ao painel de controle. Ao selecionar um pacote, o caminho mais curto, todos os caminhos, e o caminho inteligente para esse pacote podem ser realçados. O caminho mais curto e todos os caminhos se explicam por si só. O caminho inteligente mostra todos os caminhos mais curtos dos pacotes diretamente necessários até o plug-in selecionado. A Figura 3 mostra um exemplo.

   
   
   Figura 3. Visão de caminho inteligente das dependências
   
   
   
4. Para ajudar os desenvolvedores de plug-in a rastrear e corrigir erros, um recurso de relatório de erro foi adicionado para realçar os caminhos até os pacotes que não podem ser resolvidos. (Consulte a Figura 4.)
   
   Figura 4. Relatório de erro visual
   
   
   
5. A caixa de texto de pesquisa pode ser usada para realçar todos os plug-ins correspondentes a uma cadeia de caractere específica. Nesse caso, todos os pacotes contendo a cadeia de caractere org.eclipse.mylyn são realçados. A Figura 5 mostra um exemplo.
   
   Figura 5. Procura visual
   
   
   
6. A ferramenta de captura de tela pode ser usada para criar um PNG no Gráfico de dependências de Plug-in . (Consulte a Figura 6.)
   
   Figura 6. Captura de tela do Gráfico de dependência de plug-in
   
   
   
7. Diversos níveis de zoom foram predefinidos e estão disponíveis por meio do menu de contexto da visualização. (Consulte A Figura 7.)
   
   Figura 7. Configurando os níveis de zoom
   
   
   
8. Um alternador de número de versão foi disponibilizado para mostrar aos desenvolvedores de plug-in qual pacote específico foi resolvido. (Consulte a Figura 8.)
   
   Figura 8. Visualização do número de versão do pacote
   
   
   
9. A opção de ver os chamadores e que em é chamado do plug-in selecionado está disponível como mostra a Figura 9.
   
   Figura 9. Mostrando os chamadores e os chamados
   
   
   

Ao usar esses recursos, o plug-in selecionado na pasta <application_install>/dropins (aqui org.eclipse.emf.core) será validado com todos os plug-ins nas pastas <application_install>/dropins e <application_install>/plugins para verificação de dependência e os erros serão reportados.

Voltar para parte superior

Avançando uma etapa

O que a equipe do Eclipse fez é louvável, porém, essa funcionalidade pode ser estendida um pouco mais. A ferramenta mostra a dependência para um único plug-in por vez, mas como discutimos na primeira seção, precisamos descobrir se todos os plug-ins e pacotes em nosso recurso estão totalmente resolvidos. Em vez de se concentrar nos pacotes individualmente, é mais eficiente fornecer um caminho de pasta à ferramenta de visualização de dependência e deixá-la verificar as dependências de todos os pacotes nessa pasta de uma vez só.

Além disso, a ferramenta examina a plataforma de destino em busca de plug-ins mencionados na seção Required Bundle do MANIFEST.MF e informa os plug-ins ausentes. Mas, e quanto aos pacotes importados não resolvidos?

Escrevemos um pequeno código sobre o projeto do Eclipse PDE para implementar isso e simplificar e facilitar a análise das dependências de plug-in. Veja abaixo os detalhes:

Configuração e uso

• Reverta a instalação feita na seção 2.1. Consulte a documentação para reverter para a instalação anterior do Eclipse em http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-123.htm.

• Copie o arquivo org.eclipse.pde.visualization.dependency_1.0.0.jar fornecido com este artigo em seu diretório Eclipse/plug-ins e reinicie o Eclipse. (Consulte Download.)

• Vá até Window>Show View>;Other>Graph Plug-in Dependencies view ou pressione Ctrl+3 e selecione Graph Plug-in Dependencies view para abrir a ferramenta.

Validando todos os plug-ins em uma pasta

Isso permite a validação de todos os plug-ins na pasta especificada. Esse recurso economiza tempo, pois não é necessário clicar com o botão direito do mouse e selecionar Focus On… para cada plug-in. O relatório para pacotes não resolvidos é consolidado e exibido em um único lugar.

Observação: os plug-ins na pasta especificada em Plug-ins Location também devem ser incluídos na plataforma de destino ativa. (Consulte a Figura 10.)

Clique em Apply e uma lista com todos os pacotes não resolvidos deverá ser exibida sob o hiperlink em vermelho. A Figura 11 mostra 32 erros que foram detectados com o gráfico de dependência no último pacote na pasta especificada.

Basicamente, nosso código:

1. Passa por todos os plug-ins na pasta especificada,
2. Verifica as dependências de cada plug-in e
3. Adiciona todas as dependências não resolvidas aos "erros detectados".

Para ver o gráfico de dependência de cada plug-in, use as opções Back e Forward clicando com o botão direito do mouse ou na barra de ferramentas. (Consulte a Figura 12.)

Funcionalidades restantes, como

• Mostrar versão do pacote,
• Mostrar caminho de dependência,
• Mostrar os chamados e
• Mostrar os chamadores

funcionam da mesma maneira que antes.

Informando erros de pacote de importação não resolvido

As dependências de um pacote podem ser especificadas em Required Plug-ins ou Imported Packages na seção Dependencies de MANIFEST.MF. O pacote será totalmente resolvido somente quando os "Required Plug-ins" e aqueles que estiverem exportando os pacotes mencionados em "Imported Packages" estiverem disponíveis. O projeto Eclipse PDE informa somente os erros de "Required Plug-ins" e ignora os pacotes não resolvidos.

Fizemos outras alterações para mostrar pacotes de importação não resolvidos (com intervalo de versões) para o pacote selecionado. (Consulte a Figura 13.)

• A lista de erros conteria primeiro todos os "Required Plug-ins" ausentes e, depois, os pacotes não resolvidos.
• As importações opcionais são ignoradas.

Observe que, ao usar o recurso mencionado na seção 3.2, somente os "Required Plug-ins" ausentes serão informados no relatório de erro para todos os plug-ins na pasta especificada e não os pacotes de importação não resolvidos.

Os detalhes de importação ausentes são fornecidos no nível de plug-in único e podem ser vistos usando as opções Back e Forward , clicando com o botão direito do mouse ou na barra de ferramentas. É possível fazer outras alterações a fim de incluir essa funcionalidade no nível da pasta e estendê-las para gerar um arquivo de log abrangente ou simplesmente exibir no console.

Em todos os casos, os pacotes de importação não resolvidos seriam exibidos somente no relatório de erro (o link em vermelho) e não no gráfico, pois a ferramenta não sabe qual plug-in exportaria esse pacote não resolvido.

Mais uma vez, o restante das funcionalidades, como

• Mostrar versão do pacote,
• Mostrar caminho de dependência,
• Mostrar os chamados e
• Mostrar os chamadores

funcionam da mesma maneira que antes.

Voltar para parte superior

Limitações e armadilhas comuns

• A ferramenta fornece análises de dependência somente para plug-ins e não para fragmentos.
• Ela valida um plug-in específico com outros mencionados somente na plataforma de destino ativa. Não tem como a ferramenta sugerir uma resolução para os plug-ins ausentes exigidos ou para importações não resolvidas.
• O código foi compilado e testado com o IBM JRE versão 1.5.

Voltar para parte superior

Conclusão

Este artigo demonstra a ferramenta de visualização de dependência fornecida pelo Eclipse PDE com algumas modificações personalizadas com o objetivo de fornecer um conjunto de visualizações para auxiliar com tarefas de análise de dependência de plug-in. Em particular, as visualizações fornecerão suporte cognitivo aos desenvolvedores à medida que eles tentam entender as dependências entre seus plug-ins.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Todos os artigos e tutoriais sobre o projeto Eclipse IDE Navegue por essa lista abrangente de artigos e tutoriais sobre o desenvolvimento no Eclipse IDE. Veja a lista de acordo com o produto, título, tópico ou palavra-chave e classifique seus resultados.
  
  
• developerWorks no Twitter: siga-nos para acompanhar as últimas notícias.
  
  
• Zona de software livre do developerWorks: você encontra muitas informações sobre instruções, ferramentas e atualizações de projetos para ajudá-lo a desenvolver com tecnologias de software livre e usá-las com produtos da IBM.
  
  
• Eventos interessantes: confira futuras conferências, exposições e webcasts interessantes para desenvolvedores de software livre IBM.
  
  
• Podcasts do developerWorks: escute entrevistas e explicações interessantes para desenvolvedores de software
  
  
• demos gratuitas on demand do developerWorks: Acompanhe nossas demos gratuitas e saiba mais sobre as tecnologias IBM e de software livre e funções dos produtos.
  
  

Obter produtos e tecnologias

• Ferramenta de Visualização de dependência do Eclipse: faça o download da ferramenta na página da Web do projeto.
  
  
• O Eclipse Marketplace é um portal conveniente em que é possível encontrar ofertas comerciais e de software livre relacionadas ao Eclipse. Se você fizer o download do Indigo por meio de um pacote, terá acesso ao cliente Eclipse Marketplace.
  
  
• software de avaliação da IBM: inove o seu próximo projeto de desenvolvimento de software livre usando software para teste, disponível para download ou em DVD.
  
  

Discutir

• comunidade do developerWorks: Conecte-se a outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores. Ajude a desenvolver o software livre do mundo real na comunidade do developerWorks.
  
  

Sobre os autores

Nikhil Mayaskar trabalha com a equipe da IBM Cognos nos Laboratórios de software da Índia, em Pune. Sua área de experiência e interesses são Java/J2EE, OSGi e tecnologias da Web. Ele já escreveu artigos para o developerWorks e para o IBM Redpapers. Em seu tempo livre, Nikhil gosta de ouvir música e assistir a filmes. Possui um bacharelado de tecnologia em engenharia elétrica pela T-BHU, Índia.

Amit Mittal trabalha na equipe Cognos nos Laboratórios de software da IBM na Índia, em Pune. Suas áreas de experiência são Java/J2EE, OSGi e diversas outras ferramentas de desenvolvimento. Amit concluiu seu mestrado em aplicativos para computador em 2002 e tem mais de nove anos de experiência com o desenvolvimento de softwares. Em seu tempo livre ele gosta de assistir a filmes, ouvir música e procurar por avanços em ciência e tecnologia.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• O link ausente, entendendo o problema
• Projeto Eclipse PDE – Visualização de dependência
• Avançando uma etapa
• Limitações e armadilhas comuns
• Conclusão
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais