Artigo Java Magazine 37- Criando Plug-ins para o Eclipse

Criando Plug-ins para o Eclipse

Iniciando com o Eclipse Plug-in Development Environment

Aprenda a criar plug-ins, dos conceitos fundamentais a um exemplo completo e passo a passo, e tire ainda mais proveito do Eclipse

A possibilidade de customização é, sem dúvida, um dos pontos que devem ser considerados durante a escolha de uma ferramenta de desenvolvimento. O Eclipse oferece muitas facilidades de personalização e extensão, e não é à toa que se tornou líder de mercado. Neste artigo abordaremos o funcionamento dos plug-ins desta IDE e os passos para criar um plug-in totalmente funcional, para o Eclipse 3.x.

A arquitetura do Eclipse

Grande parte do sucesso do IDE Eclipse deve-se à sua arquitetura extensível (“uma IDE aberta e extensível para tudo e nada em específico”). O Eclipse (neste artigo usaremos “Eclipse” para nos referir ao IDE e não ao projeto como um todo) é constituído de um pequeno núcleo e um imenso conjunto de plug-ins, que trabalham em conjunto para fornecer as diversas funcionalidades da IDE[1].

A plataforma Eclipse gerencia todo o ciclo de vida dos plug-ins, sendo responsável por localizar, carregar e executar os plug-ins instalados. Quando o Eclipse é iniciado ele “descobre” quais plug-ins estão disponíveis (procurando no diretório plugins) e constrói um repositório, denominado plug-in registry, que é utilizado posteriormente para carregar os plug-ins[2]. A Figura 1, adaptada da documentação do Eclipse, ilustra a arquitetura da plataforma e do SDK (que a inclui) e seus principais componentes.

Figura 1. Arquitetura do Eclipse.

Para permitir extensibilidade, o Eclipse foi projetado com baixo acoplamento entre suas partes, e é um ótimo exemplo de arquitetura modular e extensível. Com a exceção de um pequeno núcleo de runtime, todas as outras partes do Eclipse são plug-ins. A customização da IDE é conseguida estendendo-se seus plug-ins, o que é feito através de extension points (“pontos de extensão”).

A idéia é simples: sempre que um plug-in deseja permitir a extensão ou a customização de uma de suas funcionalidades, ela deve declarar um ponto de extensão. Os pontos de extensão definem “contratos” (normalmente documentos XML e interfaces Java) que devem ser obedecidos pelos plug-ins que implementam a extensão/customização. É interessante notar que o plug-in que está sendo estendido não conhece (nem precisa conhecer) cada implementação específica. Isso permite que plug-ins de diferentes autores trabalhem conjuntamente com facilidade.

Enquanto alguns plug-ins são extremamente complexos e compostos de arquivos de diversos tipos, outros são simplesmente bibliotecas Java que podem ser utilizadas por outros plug-ins. A plataforma Eclipse é organizada em níveis de plug-ins, com plug-ins de “baixo nível” fornecendo pontos de extensão para plug-ins de mais alto nível. Alguns dos plug-ins básicos são:

·Standard Widget Toolkit (SWT): conjunto de ferramentas que oferecem uma API gráfica portável e integrada com o sistema operacional (SO). O SWT utiliza JNI para acessar as bibliotecas gráficas nativas do SO e renderizar os componentes gráficos utilizados na IDE (botões, imagens, labels etc.);

·JFace: extensão de “alto nível” do SWT, que oferece mecanismos para construção de diálogos, wizards, actions etc. O JFace implementa a arquitetura MVC;

·Java Developer Toolkit (JDT): ferramentas para manipulação de código Java;

·GEF (Graphical Editing Framework): APIs para construção de editores gráficos;

·EMF (Eclipse Modeling Framework): APIs para construção de modelos;

·Help: ferramentas para criação de arquivos de ajuda;

·Team: APIs para acesso a repositórios e versionamento de arquivos.

Além desses, dois outros plug-ins merecem atenção especial: o Workbench (interface gráfica comum para recursos e ferramentas) e o Workspace (que gerencia os recursos relativos aos projetos criados pelo usuário). Extensões do Workbench permitem alterar a “aparência” do Eclipse, criando novas views[3], menus e editores, enquanto que extensões do Workspace permitem interagir com novos recursos, como projetos e arquivos.

Estrutura de um plug-in

A partir da versão 3.0 do Eclipse, a descoberta e a ativação de plug-ins passaram a ser comandadas por um mecanismo baseado no Open Services Gateway initiative (OSGi). O uso dessa tecnologia melhorou a portabilidade da ferramenta entre diversos sistemas operacionais e fez com que os plug-ins passassem a ser implementados segundo um novo modelo (OSGi bundles).

O OSGi foi concebido originalmente para aplicações móveis, mas ao poucos tem sido adotado por aplicações fora desse mercado. Seu objetivo é padronizar a maneira como os componentes devem ser registrados em uma aplicação, permitindo que sejam carregados ou descarregados dinamicamente. O OSGi tem ganhado bastante destaque ultimamente, e diversos projetos da Apache já utilizam a tecnologia (ex.: Apache Directory).

Plug-ins podem ser compostos de diversos tipos de arquivos (classes, imagens, bibliotecas etc.), e incluem descritores com informações sobre suas características (versão, classpath, pacotes exportados, pontos de extensão, classes envolvidas, ícones etc.). Essas informações são usadas pelo Eclipse para configurar o ambiente de execução do plug-in e seus componentes.

Antes da versão 3.0 do Eclipse, cada plug-in era armazenado em um diretório próprio (um subdiretório do diretório plugin) e todas as informações do plug-in estavam contidas no arquivo plugin.xml, também localizado nesse diretório. Após a migração para o modelo OSGi, os plug-ins passaram a ser empacotados em arquivos JAR[4]. Além disso, as informações básicas sobre suas características foram movidas para o arquivo de " [...] continue lendo...