You’ve been asking for it, we’ve even joked about it – now it’s here (for real): for the one year anniversary of Bitbucket joining Atlassian, we are happy to announce Git support.

All your source, all in one-place

Whether you are using Hg or Git, you can now keep all of your code in one place with your preferred DVCS format. If you have existing code you would like to migrate, you can easily import your Git, Mercurial or Subversion source code. We have added a new importer for GitHub to our existing site importers which include SourceForge, Google Code and Codeplex.

Mas daí você me pergunta: “Porque usar o Bitbucket para armazenar meus repositórios Git em vez de usar o tradicional GitHub?”

Bom, se você está desenvolvendo projetos Open Source, provavelmente o GitHub seja uma opção mais apropriada, já que ele se tornou referência. Muitas empresas pedem que candidatos adicionem o seu endereço GitHub nos currículos. Já BitBucket eu nunca vi.

Em compensação, se você está desenvolvendo projetos fechados, aí o Bitbucket é vantajoso. Em todos os planos, o número de repositórios privados é ilimitados. Na conta gratuíta, a limitação fica por conta do número de usuários: 5 no máximo, o que é mais do que suficiente para 99% das startups (o SIGA é uma delas). Já para empresas maiores, por 80 dólares por mês você tem direito ao plano UNLIMITED: repositórios ilimitados e usuários ilimitados! No GitHub o maior plano custa 200 dólares mensais, e dá direito a no máximo 125 repositórios privados.

Dos vários aspectos que me impressionaram e agradaram na minha curta passagem pelo Apontador, um que me agradou muito foi a concentração de pessoas boas que tinham projetos pessoais interessantes e funcionando, com pinta de sistema profissional. Corroborou mais uma das minhas teorias sobre empresas PONTOCOM: atraem pessoas diferentes, que gostam de criar e resolver problemas.

Eu gostaria de citar dois destes projetos, que eu usei e que realmente me ajudaram.

O primeiro é o Cruzalinhas, desenvolvido pelo Chester. Parafraseando o site, o Cruzalinhas permite que uma pessoa “saiba quais linhas de ônibus, trem ou metrô passam perto de um lugar em São Paulo”. A interface não poderia ser mais intuitiva: clique em um ponto do mapa da cidade, e veja todas as linhas de ônibus e metrô que passam por perto. Clique em um segundo ponto, e veja todas as linhas que podem potencialmente levá-lo de um lugar para o outro.

O segundo é o Encontre Seu Pacote, criado pelo Thiago Ganzarolli, colega de UNICAMP. O sistema permite rastrear os pacotes enviados por SEDEX em um mapa, por RSS ou via Direct Message do Twitter. O screencast deles, plagiado abaixo, explica melhor o funcionamento.

Programação orientada a linguagens é um termo pra descrever a idéia de usar várias linguagens específicas de domínio (domain specific languages, DSLs) para desenvolver software. DSLs são linguagens criadas com um escopo limitado, o “domínio”. A vantagem de uma DSL é que ela contém abstrações bem próximas ao domínio, então em teoria usuários conseguem se expressar mais facilmente do que em uma linguagem de propósito geral (general purpose language, GPL). Por exemplo, lex e yacc são DSLs para descrever lexers e parsers, respectivamente. Você não vai escrever o compilador inteiro com elas, mas são ótimas, concisas, pra descrever aquele domínio específico. Se você fez um curso de compiladores sabe muito bem o trabalho que daria pra escrever o lexer e o parser “na mão”.

Um problema de se usar várias DSLs pra desenvolver um sistema é que nem sempre os domínios de cada DSL são tão bem separados como no caso de lexers, parsers e o backend do compilador. Muitas vezes as linguagens precisam interagir mais. Por exemplo, imagine que você tem um programa em Java e em alguma parte precisa definir uma máquina de estado. Um jeito é implementar a máquina de estado direto em Java. Outro jeito é criar uma DSL pra máquinas de estado, vamos chamar de SML (state machine language), que você pode reusar em vários projetos e que esconde detalhes da implementação Java. Mas então o código fonte teria que conter código Java e código escrito em SML. O problema é que as duas linguagens interagem, e escrever um compilador que entenda Java e SML é complicado.

É aí que entram projectional language workbenches. A idéia principal, a meu ver, é que o sistema é apresentado e desenvolvido por intermédio de projeções. DSLs são utilizadas pra descrever projeções do sistema e elas são compostas como meta-modelos. Por exemplo, você pode ver e manipular a sua máquina de estado usando uma projeção em Java ou uma projeção em SML. A sintaxe concreta usada pra cada projeção é definida por editores e você pode ter diversos editores pra uma linguagem. Por exemplo, SML pode ter uma sintaxe textual pra máquinas de estado, ou pode ter uma linguagem visual que mostre os estados e as transições como nós e setas. O que importa é que quando se manipula os conceitos no editor, se está manipulando o sistema através dessa projeção.

E qual é a vantagem? A principal, eu acho, é que se elimina o frontend do compilador e com isso vários dos problemas de se combinar linguagens. Ou seja, não existem mais lexers ou parsers, tudo o que existe é a abstract syntax tree (AST). O editor de Java não é um editor de texto, é um editor estruturado que permite manipular a AST diretamente. Dessa maneira, editores de diferentes linguagens podem ser compostos. Por exemplo, no seu editor de Java você pode visualizar a máquina de estados com o editor de SML.

E as desvantagens? Bom, eu acho que ainda existem muitos problemas. Não está claro ainda se desenvolvedores vão ser produtivos em editores estruturados. O fonte do sistema fica dependente de uma certa ferramenta (não se tem mais texto que pode ser compilado por diferentes ferramentas, se tem a descrição do sistema usando o meta-modelo específico daquela ferramenta). Além disso, ainda não está claro que tipo de problemas vão ocorrer agora que estamos compondo linguagens em um nível mais alto de abstração.

E onde pode-se ver esses conceitos em ação? Eu aconselho dar uma brincada com MPS. MPS é uma implementação bastante sólida de projectional language workbenches sendo desenvolvida pela Jetbrains (que faz o IntelliJ IDEA). Em MPS você pode criar DSLs e combinar com Java e outras DSLs. O Markus Voelter criou também uma implementacão em C pra desenvolver sistemas embarcados, num projeto chamado mbeddr.

Será que projectional language workbenches vai ser o jeito de se programar no futuro? Não sei (provavelmente não), mas vale a pena observar o que está sendo experimentado, pois com certeza é um paradigma interessante e que pode trazer bons insights. E se tudo o que eu escrevi aqui parece abstrato demais, dê uma lida nos textos do Martin Fowler pois ele entra em detalhes. E também não hesite em fazer perguntas (eu tenho um pouco de experiência com MPS e posso tentar ajudar).

Nada é perfeito, eles não são bobos nem nada, mas a oferta já permite brincar um pouco com os serviços da Amazon e sentir o gostinho de ter uma infra mais parruda. A promoção passa a valer a partir de primeiro de Novembro deste ano, e oferece a seguinte configuração por mês:

• 750 hours of Amazon EC2 Linux Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month
• 750 hours of an Elastic Load Balancer plus 15 GB data processing
• 10 GB of Amazon Elastic Block Storage, plus 1 million I/Os, 1 GB of snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests
• 5 GB of Amazon S3 storage, 20,000 Get Requests, and 2,000 Put Requests
• 30 GB per of internet data transfer (15 GB of data transfer “in” and 15 GB of data transfer “out” across all services except Amazon CloudFront)
• 25 Amazon SimpleDB Machine Hours and 1 GB of Storage
• 100,000 Requests of Amazon Simple Queue Service
• 100,000 Requests, 100,000 HTTP notifications and 1,000 email notifications for Amazon Simple Notification Service*

To help new AWS customers get started in the cloud, AWS is introducing a new free usage tier. Beginning November 1, new AWS customers will be able to run a free Amazon EC2 Micro Instance for a year, while also leveraging a new free usage tier for Amazon S3, Amazon Elastic Block Store, Amazon Elastic Load Balancing, and AWS data transfer. AWS’s free usage tier can be used for anything you want to run in the cloud: launch new applications, test existing applications in the cloud, or simply gain hands-on experience with AWS.

O endereço é http://hginit.com. O conteúdo serve tanto para aqueles que já se convenceram da utilidade e precisam entender o modus operandi (que foi o meu caso), como para os céticos que não deram muita bola e precisam ser convencidos.

E acreditem: o texto convenceu até The One Who Can’t Be Named.

Não é pouca porcaria não….

• Linguagem de programação de propósito geral, com ambiente de execução (runtime environment) implementado numa máquina virtual;
• Possui suporte “embutido” para concorrência, distribuição, e tolerência à falhas.
• É “Open-Source”, distribuído através da licença “ERLANG PUBLIC LICENSE“, que é essencialmente a Mozilla (Netscape) Public Licence, porém com algumas poucas modificações para torna-la compatível com a legislação Sueca.
• É escrito em C, e é  portável para diversas plataformas.
• Muito escalável!  Sua máquina virtual é responsável pela criação de “processos leves” de forma  rápida e barata, tanto em termos de utilização de recursos de CPU como de memória. Em outras linguagens de programação, normalmente estes serviços são delegados para o sistema operacional, o que limita  o número máximo de processos simultâneos permitidos.
• Para modelar um sistema um Erlang nós usamos: “COP – Concurrency Oriented Programming”.
• Não existe estado compartilhado…
• Variáveis podem ser atribuídas apenas uma única vez. (Single assignment variables)
• Os processos se comunicam entre si através do envio de mensagens (cópias imutáveis) assíncronas.
• Tipicamente um código escrito em Erlang faz uso dos diversos núcleos disponíveis nas CPUs modernas, praticamente sem codificação adicional. Testes mostram que clusters com 16 máquinas executam um programa 14,55 vezes mais rápido do que o mesmo programa sendo executado numa única máquina, sem codificação adicional ou específica para isto!
• Permite a interoperabilidade com C,C++, Java, Ruby, Python, Perl, etc …
• Estudos mostram que para um mesmo projeto, o código Erlang é de 4 à 10 vezes menor que seu equivalente escrito em C++.
• Possui a biblioteca  OTP (Open Telecom Platform).
• Em situações extremas de “carga”, um sistema Erlang tende a degradar seu desempenho, mas não para de funcionar.

Dentre as várias funções interessantes oferecidas por este admin, o histórico de operações sobre os objetos merece destaque:  cada ação efetuada sobre todo e qualquer objeto através do admin é gravada em uma tabela de histórico gerada automaticamente (data, usuário, objeto modificado, natureza da modificação), que pode ser visualizada em uma tabela web.

Infelizmente, este histórico é gerado automaticamente apenas para ações efetuadas através do admin. Recentemente, tive a necessidade de gravar o histórico de operações efetuadas por tarefas em background no SigaSeuTime (envio de anúncios comerciais para o Twitter), que me permitissem controlar de forma unificada e centralizada o bom funcionamento do sistema.

Pesquisando um pouco, descobri como fazer isso de forma simples com um código pequeno, que vou reproduzir abaixo:

from django.contrib.admin.models import LogEntry
from django.contrib.contenttypes.models import ContentType


def gravahistorico(objeto, mensagem, usuario):
         LogEntry.objects.logaction(
                    userid         = usuario.id,
                    contenttypeid = ContentType.objects.getformodel(objeto).pk,
                   objectid       = objeto.pk,
                   objectrepr     = mensagem, # Message you want to show in admin action list
                   changemessage  = mensagem, # I used same
                   action_flag     = 4
          )

No verdadeiro espírito de eating your own dog food, o autor do livro colocou o código-fonte do livro no GitHub e qualquer pessoa pode fazer um fork, para fazer modificações no material. Vi que a tradução para pt_br foi iniciada, mas ainda estava tímida. Ato contínuo, fiz um fork do projeto e comecei a fazer a tradução.

A minha idéia é completar a tradução e colocar aqui no site, em uma seção separada. Obviamente, não é algo que vai ficar pronto em uma semana, ainda mais se eu fizer sozinho. Então, fica a dica: se você quer aprender a mexer com o Git, ajudar a fazer a tradução do livro enquanto usa o Git é o casamento perfeito entre teoria e prática.

Na verdade a conversa começou porque uma professora tinha pedido a mim para procurar o número de artigos que referenciavam três artigos que eu estava estudando. Esta é uma métrica bastante utilizada no meio científico para ver quão bom um artigo é. Quanto mais referências um artigo tem em um menor espaço de tempo indica quão mais importante para o meio acadêmico de uma forma geral são as idéias defendidas naquele artigo.

Para fazer esta busca, a professora sugeriu que utilizássemos uma ferramenta de busca desenvolvida especificamente para este propósito: o Citeseer. Basicamente o que esta ferramenta faz é buscar numa base de dados as informações sobre um artigo e as referências cruzadas que outros artigos catalogados na mesma base de dados tem com este artigo buscado. Fiz uma busca para os três artigos que eram meu foco e… nada. Não me lembro exatamente dos resultados, mas acho que um nem foi encontrado e os outros dois, apesar de terem sido encontrados, não eram referenciados por ninguém.

O problema, neste caso, era que eu estava trabalhando com artigos muito novos, publicados no final do ano passado. Como o Citeseer, se não me engano, nem utiliza uma base de dados própria, não havia tido tempo suficiente para esta base de dados, que é alimentada com dados de algumas das principais organizações de pesquisa do mundo (no caso de computação, por exemplo, ACM e IEEE), fosse devidamente atualizada pelos diversos intermediários até chegar ao pessoal do Citeseer.

Tentei, então, o CiteseerX, uma versão nova da engine do Citeseer que ainda está na versão beta. Sem sucesso também.

A minha última tentativa foi, então, o Google Scholar. Bom, ele pelo menos conseguiu identificar os meus artigos (provando mais uma vez que o Google realmente consegue indexar algumas coisas bem rápido). Mas ainda assim meus artigos não eram referenciados. Tudo bem. Eles eram novos e isso era de se esperar.

Mas ai, no meio disto tudo, veio à tona três perguntas interessantes: você já usou outra ferramenta de busca que não o Google? Se sim, quando e porque você mudou para o Google? Será que um dia vamos parar de usar o Google?

Muita gente que eu conheço sempre usou o Google. Acho que estas pessoas teriam ainda mais dificuldades de mudar de ferramenta de busca um dia, eventualmente, se isto acontecesse.

Bem, este não é o meu caso. E toda esta conversa que tivemos me fez lembrar de quando comecei a usar a Internet. Este ano faz quinze anos (nem eu imaginava que já era tanto tempo). Em 1994, a World Wide Web estava engatinhando ainda. As ferramentas de busca, idem.

Na verdade, em 1994 não existia nenhuma ferramenta de busca que merecesse este nome para falar a verdade. Naquela época, eu e muitos outros colecionávamos os endereços que achávamos mais interessantes. Eu tinha uma planilha que chegou a ter cerca de 200 endereços catalogados e divididos em categorias. Nesta época eu já via a necessidade de ter uma ferramenta de busca (que fosse uma busca na minha planilha), mas eu não tinha conhecimento técnico para fazer isto — infezlimente; se tivesse, talvez eu estaria milhionário hoje.

O fato é que, naquela época, agrupar endereços em diretórios era tudo o que dava para ser feito. Foi assim que nasceu, também em 1994, o “Jerry and David’s Guide to the World Wide Web”, que, ainda naquele ano passou a se chamar “Yet Another Hierarchical Officious Oracle” ou, simplesmente, Yahoo!. Mais da história inicial do Yahoo! pode ser encontrada aqui.

Eu não tive o prazer de acessar o site inicial de Jerry and David pelo meu navegador Mosaic (primeiro navegador existente e predecessor do Netscape 1.0). Mas a versão inicial do Yahoo! eu usei. Era o melhor que se tinha na época. Andei procurando no Internet Archive uma versão do site inicial do Yahoo!, onde só existia a estrutura de diretórios e nenhuma ferramenta de busca ainda. Mas nem mesmo o Internet Archive indexava páginas há tanto tempo atrás. A primeira home page do Yahoo! que existe lá é de outrubro 1996. Clique aqui para dar uma olhada (até os links funcionam! ). Nela existe a famosa estrutura de diretórios do início do Yahoo! (que deve existir até hoje) e uma ferramenta de busca (talvez a primeira da qual eu me lembre).

Eu parei de usar o Yahoo!, se não me engano, pouco antes de entrar na faculdade, em 1999. Naquela época já existia uma ferramenta de busca chamada AltaVista que conseguia atingir diversos sites que, aparentemente, não eram visitados ou corretamente classificados pelo Yahoo!. Como dizia o próprio slogan do AltaVista, ele era “The most powerful and useful guide to the Net”. O AltaVista ainda existe. Hoje ele é parte do Yahoo!, que, se não me falha a memória, em um determinado ponto no tempo comprou a engine do AltaVista para utilizar em suas próprias buscas. Eu, no entanto, não voltei a usar o Yahoo! como ferramenta de busca.

Até que, já lá para o meio do meu tempo de faculdade, muitas pessoas vinham me falar do Google. Com o tempo, as buscas que eu fazia no AltaVista já não pareciam tanto satisfatórias. E, quando eu, insatisfeito, ia até o Google e repetia a mesma busca, ele me retornava resultados melhores. Com o tempo, fui largando o AltaVista e passei a usar somente o Google.

Como já comecei a usar o Google quando ele era uma ferramenta estável, usei o Internet Archive para buscar as primeiras versões da página do Google. É interessante notar que a primeira página registrada para o Google no Internet Archive (que, neste caso, deve ser a primeira página deles mesmo) não era tão diferente da atual e o nome Google aparecia com um ponto de exclamação no final  (“Google!”)… será que isto tinha alguma coisa a ver com o então maior site de busca do momento “Yahoo!”? Yahoo!, inclusive, para o qual o engine criado por Larry Page e  Sergey Brin (fundadores do Google) foi oferecido e rejeitado, o que levou à criação do Google. Mas isto é outra história…

Bom, o fato é que o tempo foi passando e hoje o Google, para mim, está agregado em rotinas automáticas no meu computador. Para falar a verdade, não acesso mais a ferramenta de busca pela página web do Google já faz muito tempo. Uso apenas o plug-in de busca para o Firefox ou o Google Desktop para fazer isso. Com isto, fica cada vez mais difícil a mudança para outra ferramenta de busca, na minha opinião, pois tudo já está pronto e funcionando assim.

No entanto, isto não quer dizer que não existam outras opções. Ano passado foi lançado o Cuil (leia-se “cool”), um site de busca criado por ex-funcionários do Google. O grande diferencial do Cuil seria a não utilização da popularidade de uma página como item preponderante no cálculo de relevância da página, o que pode ser bem interessante em alguns casos, especialmente quando se busca conhecimento e não simplesmente popularidade. No entanto, eles mesmo adimitiam na época que não era necessário apenas uma boa ferramenta de busca: o maior trabalho estaria em quebrar a inércia dos usuários (a minha, por exemplo, como descrevi no parágrafo anterior, é bem alta).

Outra que sempre tentou desbancar o Google foi a Microsoft. Ano passado ela tentou comprar o Yahoo!. Não deu certo. Este ano ela lançou o Bing, sua nova ferramenta de busca. Apesar do visual mais bacana que o do Google (na minha opinião) e de ele vir embutido em vários produtos da Microsoft, isto não foi suficiente para mudar a inércia do usuário.

Sinceramente, eu acho que a única maneira de quebrar esta inércia do usuário em relação às ferramentas de busca que ele usa é criar algo que o Google ainda não oferece (não me pergunte o que… se eu soubesse não estaria escrevendo este post, mas sim implementando esta idéia ). Ou fornecer ferramentas de busca que retornem resultados mais aprimorados que os do Google em campos nos quais o Google talvez não seja satisfatório. Eu listaria como dois campos em que o Google está longe de ser satisfatório em relação às buscas, na minha opinião, as buscas por imagens e por vídeos. O “Santo Graal” nestas áreas, por mim, seria conseguir fazer busca não pelos textos das páginas em que as figuras ou os vídeos aparecem, mas sim fazer busca pelo significado das imagens e dos vídeos mesmo. Algo que eu acho que a computação ainda está um pouco longe de conseguir fazer de forma automática e eficiente.

Opiniões pessoais a parte, eu passei três anos, de 2006 a 2008, não apenas utilizando o Eclipse como plataforma de desenvolvimento mas também como produto final do meu trabalho. Ou seja, eu não só desenvolvi no Eclipse. Eu desenvolvi O Eclipse.

Muitas pessoas escutam falar que o Eclipse é uma plataforma extensível. Afinal de contas, se fosse diferente, certamente não teríamos os incontáveis plug-ins para Eclipse que adicionam inúmeras funcionalidades interessantes. O que talvez nem todo mundo saiba é que extender o Eclipse é muito fácil! E talvez por não saberem disso, acabam achando que é algo difícil e não se aventuram por este mundo interessante.

O melhor de tudo é que para extender o Eclipse a única coisa que você precisa é do própio Eclipse! Ou seja, a melhor ferramenta para desenvolver o Eclipse é o próprio Eclipse.

Neste artigo vou abordar o passo-a-passo de como criar um plug-in simples para o Eclipse.

Primeiramente, alguns conceitos. O Eclipse possui o que chamamos de pontos de extensão (extension points). Estes são arquivos XML que possuem configurações que definem possíveis extensões do Eclipse. A plataforma básica já fornece uma série de pontos de extensão que podem ser facilmente utilizados para extender as funcionalidades já disponíveis (por exemplo, neste mini-tutorial iremos criar um novo menu com uma ação específica). À medida em que você for ganhando mais traquejo na implementação de pontos de extensão, você vai naturalmente notar a necessidade de você mesmo criar seus próprios pontos de extensão a partir de coisas que você extendeu anteriormente da plataforma básica (espero falar disso em um post futuro).

Mas vamos ao que interessa a este tutorial. Para começar você vai precisar ter instalado uma máquina virtual Java. Sugiro as da IBM ou da Sun, já que elas funcionam muito bem com o Eclipse. Um aviso aos usuários de Linux: as máquinas virtuais que veem com as distros (GCJ ou iced-tea) em geral não funcionam corretamente e possuem bugs em funcionalidades básicas, tornando difícil ou impossível rodar o Eclipse com elas. Se você já roda o Eclipse como plataforma de desenvolvimento você certamente já possui uma máquina virtual Java instalada.

Depois é necessário instalar o Eclipse SDK. Outro aviso aos usuários Linux: também não recomendo os empacotamentos de Eclipse SDK que vem com as distros. Em geral são ligeiramentes diferentes em relação ao Eclipse distribuído pela Eclipse.org e, muitas vezes, possuem bugs que não existem na versão original.

Quando usado como plataforma de desenvolvimento para Java ou C/C++ não é necessário ter o Eclipse SDK instalado. Basta o runtime do Eclipse. Para instalar o Eclipse SDK basta certificar-se de que você baixou o pacote com o nome Eclipse SDK do site Eclipse.org ou que você tenha instalado a feature “Eclipse Project SDK” através do Update Manager do Eclipse runtime.

Bom, feito isso, siga os seguintes passos:

1) Crie um novo projeto de desenvolvimento de Plug-In para Eclipse.

1.1) Clique no menu File -> New -> Project….

1.2) Selecione a opção Plug-in Development -> Plug-in Project na janela que se abrir e clique no botão “Next”.

1.3) Dê um nome para seu projeto, por exemplo org.eclipse.test e clique no botão “Next”.

1.4) Clique no botão “Next” no próximo passo do Wizard, chamado de “Content”.

1.5) No passo de escolha de Templates, selecione o template “Hello, World”. Clique no botão “Next”.

1.6) No último passo do wizard, não altere nada e clique no botão “Finish”.

2) O Eclipse irá perguntar se você deseja alterar a Perspectiva atual para a Perspectiva de desenvolvimento de plug-ins. Clique em “Yes”.

3) O Eclipse abrirá o editor no arquivo MANIFEST.MF. Este arquivo define as características de seu plug-in como, por exemplo, de quais outros plug-ins ele depende, quais pacotes ele exporta, quais extension points ele extende, quais extension points ele provê e outras configurações. Não vou me ater a este arquivo pois ele não será realmente importante para o desenvolvimento deste caso simples.

4) Utilizando este Template “Hello, World”, você verá que o Eclipse criou uma pasta src/org.eclipse.test.actions com uma classe SampleAction.java. Abra esta classe no editor dando um duplo clique no arquivo.

5) Esta classe possui um método public void run(IAction action) que define qual ação será executada ao se clicar no menu que estamos criando. No caso deste template, a ação executada é bem simples: abre-se uma janela com uma mensagem de “Hello, Eclipse world”.

6) Para ver seu plug-in em ação numa instância de Eclipse não é necessário instalá-lo, ainda. O Eclipse provê uma funcionalidade através da qual, de dentro do Eclipse, você pode lançar um novo Eclipse que carregará os plug-ins que você está desenvolvendo no seu workspace. Para fazer isto você terá que “executar” seu plug-in de maneira semelhante ao que você já faz para suas aplicações Java ou C/C++.

6.1) Clique no menu Run -> Run Configurations….

6.2) Dê dois cliques em “Eclipse application” no lado esquerdo da janela que se abrir. O Eclipse criará um novo launcher para aplicação Eclipse que, por padrão, a incluirá os plug-ins que estão no seu workspace.

6.3) Clique no botão “Run”.

7) Um novo Eclipse será executado. Note que nele aparecerá um menu novo, que não existia na instância anterior de Eclipse, com o nome “Sample Menu”. Clique em Sample Menu -> Sample Action.

Uma janela será aberta com a frase que você definiu na classe SampleAction.java.

Parabéns! Você acaba de criar um plug-in para Eclipse ao extender o extension point que permite a adição de novas opções de menu ao Eclipse.

Um tutorial semelhante a este pode ser acessado de dentro do próprio Eclipse através das “Cheat Sheets” providas pelo Eclipse SDK. Clique em Help -> Cheat Sheets… e depois selecione a opção Plug-in Development -> Creating an Eclipse Plug-in na janela que se abrir. Selecione “Create a plug-in” na view que se abrir e siga os passos descritos na tela. Este tutorial, apesar de estar em inglês, possui uma quantidade bem legal de informações sobre como criar plug-ins para Eclipse com links explicando vários conceitos relacionados. Vale a pena!