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
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
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 manifest (META-INF/MANIFEST.MF). Assim, plug-ins construídos a partir da versão 3.0 contêm dois descritores: plugin.xml e MANIFEST.MF.
O arquivo plugin.xml
O documento XML a seguir, extraído da documentação do Eclipse, ilustra um descritor de plug-in simples, que implementa uma nova view no Eclipse.
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension point="org.eclipse.ui.views">
<category name="Hello Category"
id="com.example.helloworld">
</category>
<view name="Hello View"
icon="icons/sample.gif"
category="com.example.helloworld"
class="com.example.helloworld.HelloWorldView"
id="com.example.helloworld.HelloWorldView">
</view>
</extension>
</plugin>
A implementação da nova view é conseguida através do uso do ponto de extensão org.eclipse.ui.views, indicado no elemento <extension>. No elemento <category> são descritos o nome (name) e o código identificador (id) da categoria. A nova view é descrita no elemento <view>, onde são indicados seu ícone (icon), a referência à sua categoria (category), a classe implementadora (class) e o código identificador da nova view (id). Os atributos de “baixo nível” do plug-in (ex.: informações sobre como o plug-in deve ser empacotado) são descritos no arquivo MANIFEST.MF que, por simplicidade, não é mostrado neste artigo.
Como veremos adiante, o Eclipse disponibiliza recursos que facilitam muito a geração e manuseio dos descritores de plug-ins (plugin.xml e MANIFEST.MF).
Plug-in Development Environment (PDE)
Vimos que a plataforma Eclipse é responsável por gerenciar todo o ciclo de vida de um plug-in, escondendo do desenvolvedor os detalhes de infra-estrutura. Assim, o desenvolvedor passa a se preocupar apenas com a implementação da “lógica de negócios” do plug-in, podendo aproveitar os recursos de uma ferramenta bastante valiosa (que também é um plug-in!): o Eclipse PDE. O Plug-in Development Environment é um ambiente completo para desenvolvimento de plug-ins, que contempla recursos para sua construção, teste, depuração e empacotamento. O Eclipse SDK já inclui o PDE, que vem configurado e pronto para uso.
Um exemplo completo
As funcionalidades do PDE serão apresentadas através do desenvolvimento completo de um plug-in que automatiza a codificação de caracteres especiais.
Quando escrevemos documentação javadoc ou arquivos de propriedades (.properties) é um boa prática utilizar codificação HTML para caracteres especiais, permitindo que o texto seja exibido corretamente em diversos browsers. Desse modo, o caractere “ã” deve ser substituído por “ã”, o caractere “ç” por “ç” e assim sucessivamente (veja referência ao final do artigo).
O maior problema dessa abordagem é que o desenvolvedor deve conhecer os códigos dos caracteres e digitá-los corretamente. O nosso plug-in fará isso automaticamente, substituindo caracteres especiais por seus correspondentes em HTML.
A utilização do plug-in será feita da seguinte maneira: o usuário seleciona, no Package Explorer, o arquivo que deseja editar, clica com o botão direito e seleciona no menu popup o item correspondente. Todos os caracteres especiais do arquivo (que deve estar aberto no editor) serão substituídos automaticamente, e uma barra de progresso indicará o andamento da operação.
Criando o projeto do plug-in
A maneira mais fácil de criar um plug
Figura 2. Informando os dados básicos do projeto.
É possível perceber que a criação de um projeto de plug
...
