Artigo Java Magazine 23 - O Projeto Eclipse

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Neste artigo, vamos revisar toda a tecnologia produzida pela Fundação Eclipse, investigando o significado e a utilidade dos seus subprojetos, e dar uma boa visão do que vem por aí.

Esse artigo faz parte da revista Java Magazine edição 23. Clique aqui para ler todos os artigos desta edição

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML. 

Byte Code

O projeto Eclipse

Arquitetura, subprojetos, planos e ferramentas

 

Conheça cada um dos subprojetos e o que está por vir num dos projetos de maior sucesso e qualidade da história do open source.

 

Osvaldo Pinali Doederlein

 

Em poucos anos, Eclipse tornou-se um dos IDEs predominantes para Java. Mas o projeto Eclipse destaca-se por ultrapassar as fronteiras dos IDEs. Os desenvolvedores que conhecem somente a distribuição principal, o Eclipse SDK, apenas arranharam a sua superfície. Sabemos que existem IDEs comerciais mais completos, como WebSphere Studio da IBM, que complementam o IDE Eclipse com recursos adicionais. Sabemos também da existência de muitos plug-ins de terceiros, livros ou proprietários, que estendem o Eclipse para várias tarefas adicionais. Nada disso é novidade, a maioria dos IDEs atuais é bastante extensível. Mas o Eclipse vai além. Provido de uma sofisticada arquitetura de plug-ins, propõe-se a ser uma “ferramenta universal”, e a fundação Eclipse, responsável pelo seu desenvolvimento vem aumentando sem parar o escopo dos seus projetos.

O observador casual que resolva investigar todo o site eclipse.org poderá se sentir perdido em meio a uma enorme quantidade de projetos, siglas e downloads. A própria fundação não parece muito preocupada em facilitar as coisas pra o usuário final. Por exemplo, não existe um download único agrupando as últimas verões estáveis de todas as ferramentas de desenvolvimento para Java.

Neste artigo, vamos revisar toda a tecnologia produzida pela Fundação Eclipse, investigando o significado e a utilidade dos seus subprojetos, e dar uma boa visão do que vem por aí. Para os interessados em desenvolver plug-ins para o Eclipse, este artigo poderá ser importante como primeira etapa antes de se aventurar pelas APIs do Eclipse e o PDE (o ambiente de desenvolvimento de plug-ins).

Vamos começar com um pouco de história.

 

Um novo modelo de open source

 

O eclipse nasceu no estilo “catedral”, com um processo de desenvolvimento tradicional. Uma grande equipe de desenvolvedores dedicados (inicialmente 40), modelagem detalhada, cronogramas sérios e outros aspectos de um projeto da IBM ou de outra grande empresa. Para ser exato, o Eclipse é cria da antiga OTI (Object Technology International), famosa pela sua tecnologia de orientação objetos para Smalltalk e Java. Antes do Eclipse, a OTI já havia criado o VisualAge e a JVM para pequenos dispositivos J9. Há anos a OTI foi adquirida pela IBM, tornando-se uma subsidiaria da empresa e posteriormente renomeada para “IBM Ottawa Software Lab”.

No lançamento inicial do eclipse, a IBM anunciou com fanfarra a doação à comunidade open source de 40 milhões de dólares (o custo estimado de produção do Eclipse1.0), sob uma licença open source (à CPL, aprovada pela OSI).

Mas isso foi só o começo. A grande maioria dos desenvolvedores (inclusive estrelas como Erich Gamma, aquele do livro de Desing Patters) continua na folha de pagamento da IBM. É através da adesão de outras empresas e pessoas-chave, o Eclipse continua ganhando força. A qualidade, o tamanho e a velocidade do desenvolvimento dos projetos refletem a estrutura e os recursos da Fundação Eclipse - distantes de muitos projetos open source mais tradicionais, que são freqüentemente limitados por carência de recursos, fundos ou organização. Mas o eclipse também não exclui nem dificulta a participação de voluntários. Muitas melhorias já foram incorporadas por contribuintes independentes.

Projetos abertos com desenvolvimento comercial não são novidades totais. Outros projetos open source famosos também contam com muitos desenvolvedores que trabalham em tempo integral, às vezes para uma única empresa ou organização, e que recebem um contra-cheque no fim do mês pelo serviço. Exemplos são o NetBeans e o OpenOffice (Sun), JBoss (JBoss Group LLC), MySQL (MySQL AG) e o Linux.

O Eclipse só leva esse modelo “livre+comercial” a uma nova ordem de grandeza. Nunca antes uma empresa ou grupo investiu tanto, de forma continuada, num projeto de software aberto tão ambicioso. O modelo de negocio é inovado: a Fundação é uma organização sem fins lucrativos, mais seus “membros estratégicos” devem contribuir com desenvolvedores dedicados e contribuições anuais. Os “consumidores estratégicos” – em empresas com grande interesse nos produtos da fundação – pagam taxas ainda maiores (até meio milhão de dólares anuais). Pequenos fornecedores de ferramentas (“fornecedores de Add-Ins”) também podem influenciar as decisões da fundação, pagando uma taxa bem mais modesta (5 mil dólares anuais). Além disso, os mesmos contribuintes têm produtos e negócios alavancados pelos produtos livres.

Assim, a fundação não tenta arrecadar dinheiro dos usuários finais, com licenças pagas, serviços de suporte, livros e etc., como outras iniciativas de software livre+comercial. O modelo adotado é mais parecido com o de órgãos de padrões como a OMG ou W3C, exceto pelo fato que estes órgãos produzem apenas especificações, e a fundação Elipse cria produtos. É mais uma tendência importante na continua evolução do open source.

 

A plataforma Eclipse

Muitos usuários vêem o Eclipse como um “IDE Java”. Efetivamente é isso que é oferecido pelo pacote mais importante do projeto: o Eclipse SDK. Mas na verdade o Eclipse é uma plataforma sobre a quais diversas ferramentas podem ser escritas. No coração do Eclipse, existe um microkernel (núcleo de execução) que não sabe fazer outra coisa se não gerenciar plug-ins. Toda a funcionalidade real é fornecida por essas extensões. A Figura 1 ilustra a arquitetura básica. A seguir são descritos os principais componentes.

·       Runtime de Plataforma – É o programa principal, que inicializa e gerencia plug-ins (será referido apenas por “Runtime”.)

·       Workspace – Gerenciar recursos (diretórios e arquivos). Para o usuário final, “workspace” é uma estrutura de diretórios que contém os projetos do Eclipse. O componente Workspace gerencia esses workspaces, implementando esses recursos como marcadores (anotações relacionadas a recursos do workspace, como erros de compilação, tarefas, breakpoints e outras), além de projetos e eventos de alteração de recursos (usado pelo componente Team para manter o histórico local e pelos compiladores para fazer compilação incremental). Observe que nada disso envolve interfaces gráficas (GUIs).

·       SWT e JFace – Toolkits de GUI. A SWT é o toolkit fundamental e a JFace é um framework MVC que permite programação de mais alto nível. Veja o quadro “SWT versus AWT/Swing”.

·       Workbench - O coração da GUI do IDE. Implementação as entidades básicas de GUI, como a estrutura de perspectiva, Views e Editores, menus, caixa de configuração, barra de ferramentas, implementação de Editores e Views para formatos de arquivos básicos, e outros recursos genéricos de interfaces gráficas. Oferece o Suporte de GUI para todas as funcionalidades do Workspace.

·       Team – É responsável pelo controle de versões e histórico de mudanças de recursos. Não suporta um gerenciador de versões específicas, mas contém toda a funcionalidade genérica sobre a qual um plug-in para um desses gerenciadores pode ser construídos. Define elementos de GUI, WORKflow e funcionalidades gerais (como o componente Compare, que faz comparação visual entre duas versões de um arquivo). O Team também estende o Workspace para fazer versionamento local de recurso, sem nenhum servidor de repositório. Isso oferece ao Eclipse uma espécie de desfazer/refazer com estado persistência a maioria dos recursos de um gerenciador de versões – só que sem compartilhamento entre usuários e com um histórico de versões limitado (por tamanho ou tempo).

·       Debug – fornece suporte fundamental à depuração de programas não sendo específico a nenhuma linguagem ou plataforma de execução. Define a arquitetura, conceito e suporte de GUI fundamentais para depuração, tais como processos, breakpoints, visualização de variáveis, filtros etc.

·       Help – Suporte help on-line. Inclui um visualizador de help próprio, que permite construir help on-line a partir de conteúdos HTML, alem de recursos de navegação, indexação e pesquisa.

·       Update – Gerenciamento de atualizações automáticas (oferece também uma GUI para os recursos de gerenciamento de plug-ins do Runtime).

 

 

Figura 1. Arquitetura do eclipse e seus principais plug-ins. A Plataforma é o coração dos IDEs, como o JDT para Java. Os plug-ins em amarelo são específicos à linguagem Java, dependendo do JDT direta ou indireta. Mas vários outros são mais genéricos, sendo úteis também para outras linguagens, ou para tarefas que não envolvem nenhuma linguagem de programação. Neste nível de detalhe, a maioria dos componentes exibidos é de fato agregada de diversos plug-ins. Aqui explodimos o JDT, mostrando sua estrutura interna. Além disso, plug-ins de mais alto nível dependem de outros mais fundamentais; por exemplo, o JST é construído sobre o WST e o JDT, e o JDT é construído sobre a Plataforma (cujos componentes também são todos plug-ins). O grupo “Novos frameworks” apresenta componentes exigidos pela maioria das extensões mais sofisticadas (a tendência é que no futuro eles sejam incorporado à Plataforma ou ao Eclipse SDK)

 

Entendendo a arquitetura

Todos esses componentes fundamentais são exatamente genéricos. Por exemplo, o Workspace não exige uma GUI e o Workbenh não pressupõe e nem fornece nada especifico para Java (isso fica no JDT). Outro exemplo e o Team, que não exige nenhum sistema de versões particular; o suporte a CVS é implementado por um plug-ins adicional.

O grupo “Plataforma Eclipse” mostrado na Figura 1 é a base sobre a qual qualquer IDE pode ser construído (veja também o quadro “Eclipse RCP”). Sobre esta base, precisamos adiciona novos plug-ins que acrescentam suporte a alguma linguagem, ambiente ou tecnologias. Na figura são exibidos os dois principais plug-ins ¹ que fazem isso: o JDT e CDT. Cada um destes pacotes conte plug-ins que estendem funcionalidades da plataforma. Por exemplo, o Workspace define a entidade fundamental “projeto”  e possui uma GUI básica para projetos; o JDT estende esses elementos para criar um “Projeto Java”.

Exemplificando no Eclipse: crie um projeto Simples ("

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?