Arquivo da tag: Eclipse

Integração contínua é com TeamCity

Recentemente fui convidado a montar o ambiente de integração contínua de uma empresa. O trabalho inicial de verificação dos projetos, testes e builds existente foi feito como manda o figurino. Todos os projetos usavam maven2 e, felizmente, todos eles (inclusive os sub-projetos) possuíam pom’s bem configurados e completamente funcionais.

Os builds e processos internos (manuais) para builds da empresa estavam ok, verificados e funcionando. Feito isso fomos aos testes. Testes!? Ok, vamos ao próximo passo e esqueça os testes por enquanto. O controle de versão era feito com Subversion e os clientes usando Tortoise. A IDE utilizada por toda a organização era o IntelliJ IDEA, mesmo assim o cliente para o SVN era o Tortoise, ainda tento compreender isso até hoje.

wheresthebuild-smallA empresa estava em um momento de criação e manutenção de testes funcionais, então, algumas pessoas estavam trabalhando exclusivamente com Selenium. Era uma boa oportunidade, pois estes testes seriam todos automatizados no ambiente de integração contínua a ser preparado. Uma série de procedimentos foram realizados até chegarmos no ambiente de facto, mas vou pular isso para o post não ficar grande e chato de mais.

Comecei então com a preparação de alguns protótipos. Já trabalhei algumas vezes em ambientes de integração contínua com o CruiseControl e também com o CruiseControl.rb, logo pensei em utilizar um desses. Pesquisando e perguntando a conhecidos cheguei às indicações de: Hudson com muitas indicações, Continuum da Apache, TeamCity da JetBrains e Bamboo da Atlassian, sendo estes dois últimos privados e com custo para licença. Ainda assim estava considerando as duas alternativas pagas logo depois de alguma alternativa da família CC, isto porque a empresa possuía licenças do Jira e Confluence, logo o Bamboo poderia ser uma boa pedida devido a recursos de integração. E também possuíam licenças do IntelliJ IDEA, logo a integração com a IDE poderia ser um ponto positivo para o TeamCity.

Alguma coisa aconteceu comigo e na manhã seguinte eu resolvi começar pelas ferramentas que eu não conhecia. Comecei pelo Hudson, TeamCity e por último Continuum, resolvi parar por aqui pra não perder mais tempo, nesse momento já havia uma escolha muito clara e três dias já haviam se passado.

Continue lendo Integração contínua é com TeamCity

Eclipse 3.4 Ganymede

Esta semana foi anunciado o lançamento de um novo release do Eclipse, a versão 3.4, chamada agora de Ganymede.Vide Ganymede Moon, Ganymede Myth (um herói) e agora também Eclipse Ganymede, uma escolha legal para o Eclipse (pelo fato do herói :D).

Esta release anual do projeto Eclipse é chamada, por eles, de Annual Release Train. Isso devido ao fato de ser um lançamento coordenado de 23 (vinte e três) projetos que, juntos, compõem o Eclipse e mais de 18 milhões de linhas de código. Um bom exemplo de organização e disciplina.

Eu ainda não consegui migrar todos os meus projetos para o Eclipse, na verdade não abri a minha workspace principal com o Eclipse Ganymede ainda. Não, não é medo de dar algum problema, é que ainda não pude fechar o meu Eclipse Europa pra fazer isso, mas não passará deste final de semana. Em tempo, algumas coisas já consegui mudar para o Ganymede e já pude desfrutar de algumas novidades.

Dentre as coisas realmente novas as que eu mais gostei, e que com certeza serão as que mais impactarão no meu dia-a-dia do desenvolvimento são:

  1. Aplicar formatação apenas nas linhas alteradas: Seguindo no menu Window> Preferences e depois em Java > Editor > Save Actions e habilitar a opção Format edited lines e pronto, dá próxima vez que você alterar alguma classe e usar a auto-formatação apenas as linhas que você alterou serão formatadas.
  2. Drag & Drop no Outline View: Agora para cuidar da organização do código tudo pode ser feito através da View Outline apenas arrastando e soltando. Isso eu gostei muito.

Além destas muitas outras novidades acompanham esta release. A lista completa pode ser vista na página oficial da release e também no Eclipse Zone, que publicou uma notícia com muitas outras descobertas além destas que citei, vale a pena a leitura.

Migrando do Netbeans para o Eclipse

Há alguma semanas comecei a usar o Netbeans profissionalmente num dos projetos aqui da empresa. Já comentei sobre isso algumas vezes aqui no blog: aqui, aqui e aqui. Experiências com ferramentas novas (às vezes nem tão novas, afinal eu já conhecia o Netbeans há muito tempo, só não usava no trabalho) é sempre algo que gosto muito pois sempre rola muito aprendizado, melhora nossa visão e criticidade sobre uma série de pontos, e por aí vai.

E com o Netbeans não foi diferente, aprendi um pouco mais sobre detalhes da IDE, alguns atalhos, algumas manhas, também vivenciei alguns dos problemas que eu já conhecia e acabei por descobrir e sofrer com alguns outros novos. Após migrarmos para a versão 6.1 alguns novos problemas foram cruciais para a decisão da migração, como os mais importantes:

  1. CVS
    Com muita freqüência (principalmente com JSPs) o Netbeans não mostra o que há de novo ou modificado no repositório. É muito comum alguém fazer um commit de uma nova JSP, por exemplo, outra pessoa fazer um Show Changes e está JSP não aparecer na lista para o update. Às vezes conseguimos resolver fazendo direto um Update no projeto inteiro, mas não é sempre que funciona. Mesmo quando funciona há o inconveniente de estar fazendo um update às cegas, sem saber ao certo o que está vindo do repositório. Quando não funciona eu tenho que procurar o cara que colocou a JSP no projeto, pedir pra ele remover e inserir de novo, até funcionar.
  2. Indexing
    Sabe aqueles problemas horríveis que só acontecem de vez em quando ou que só acontecem com uma pessoa X ou Y? Pois é, depois da atualização do Netbeans, algumas estações praticamente todas as estações começaram a ter um problema desta espécie. Ao abrir a IDE perdia-se em média 3 minutos aguardando a conclusão da indexação do conteúdo do projeto, e não, nosso projeto não é um mega projeto. E isso não acontecia com todas as pessoas da equipe, apenas com alguns sortudos contemplados.

Como estes problemas impactam diretamente no ambiente de desenvolvimento como um todo e na integração da equipe não tivemos outra alternativa que não fosse a migração, e obviamente a IDE escolhida não poderia ser diferente, optamos pelo Eclipse :D

O processo de migração em si foi bem simples e não houve nenhum tipo de trauma. Não utilizamos ferramentas ou kits de migração, nada disso, tudo correu de forma de simples e convencional, porém muito funcional e útil.

A migração

Nosso ambiente no Netbeans era composto por dois projetos, que chamarei pelo nome fantasia de jujuba. Este era o nosso projeto web. E também tínhamos o projeto jujuba-ejb.

Como os nomes dos projetos não refletiam bem o que deve ser o projeto real do cliente nós aproveitamos a migração para arrumar isso. Então criamos num Eclipse um Enterprise Application Project chamado doceria e nele dois módulos: doceria-web e doceria-ejb, simples assim.

O primeiro passo foi conferir todas as dependências. Nesta momento vale um ponto para o Netbeans, bastaria associar o projeto a dependência desejada (jersey, pra REST, por exemplo) e pronto, tudo é feito para que o projeto compile e a API fique a sua disposição e o mesmo é feito durante o build e deploy, empacotando todas as dependências. Mas fizemos no Eclipse, pega-se os JARs, copia no web-inf/lib para o projeto web e pega-se os outros JARs, coloque-os no projeto ejb e configure se estes deverão fazer parte do EAR ou do JAR do EJB. Pronto, agora estão configuradas as dependências.

O restante foi super simples. O deploy dos dois projeto é feito no JBoss, configurar isso no Eclipse é completamente normal, apenas criamos um novo servidor no Eclipse, utilizando a instalação local do JBoss, depois bastou associar o projeto doceria ao JBoss e tudo já estava funcionando, aliás, por enquanto ainda era nada, pois os fontes ainda não haviam sido migrados.

A migração dos fontes foi a parte mais antiquada, porém a mais fácil, bastou copiar diretamente no sistema de arquivos:

Para o projeto web:

  • cd /home/jeveaux/development/java/workspace/doceria-web/src
  • cp -r /home/jeveaux/development/java/workspace/jujuba/src/java/* .
  • cd ../WebContent
  • cp -r /home/jeveaux/development/java/workspace/jujuba/web .

E para o projeto EJB

  • cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule
  • cp -r /home/jeveaux/development/java/workspace/jujuba-ejb/src/java/* .
  • cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule/META-INF
  • cp /home/jeveaux/development/java/workspace/jujuba-ejb/src/conf/ejb-jar.xml .

E pronto, foi isso, sem stress e sem complicações. Agora o projeto foi totalmente migrado para o Eclipse e está completamente funcional, igualzinho quando estávamos utilizando o Netbeans.

Mais (ainda) do mesmo

Já fazem alguns dias que foi lançada a versão do 6.1 do NetBeans, mas como andei sem tempo demorei um pouquinho pra atualizar meu (novo) ambiente de trabalho, como já comentei aqui e aqui, estou utilizando o NetBeans num dos projetos que participo.

Como ia baixar a nova versão, acabei optando pela versão full já interessado no suporte ao Ruby, coisa que ainda não testei no NetBeans pois o Aptana sempre foi legal pra mim, afinal é um Eclipse, certo? ;-) Ainda não tive tempo para testar o NetBeans com Ruby, mas farei isso ainda essa semana.

Logo de cara ao abrir os projetos no novo NetBeans o project.properties foi alterado e todos os endereços que antes eu havia mudado para caminhos relativos voltaram a ser caminhos absolutos, precisei acertar isso novamente. Todos os arquivos do projeto localizados no diretório nbproject foram alterados, não sei exatamente o motivo e nem se isso vai atrapalhar quando alguém com outra versão do NetBeans for utilizar o projeto, sinceramente fiquei um pouco preocupado.

Um novo problema que não acontecia passou a acontecer. Uma referência a um projeto com EJBs, apesar de não estar com a opção ‘Package‘ do NetBeans marcada, ou seja, o projeto referenciado não deveria ser empacotado junto com o WAR da Web Application. Mas isso não estava funcionando mais, precisei editar mais um arquivo manualmente, o build-impl.xml e retirar a tag copy-ear-war da referência problemática.

Fora os problemas, eu gostei que agora ao fazer o diff entre dois arquivos as diferenças já são abertas automaticamente, antes eu precisa mandar abrir o diff e depois clicar numa das tags exibidas. E a IDE em si também ficou mais rápida para aparecer, isso mesmo, só pra aparecer, pois pra abrir continua demorando o mesmo tempo de antes, só foi feita uma jogada pra nos tapiar. Os projetos e módulos que antes eram carregados ao iniciar a IDE agora são carregados depois que ela abre, ou seja, continua demorando do mesmo, só mudaram a demora de lugar.

No geral essa experiência está sendo muito legal, já estou bem menos reativo ao NetBeans.

Mais do mesmo: Netbeans

Nada como um bom final de semana trabalhando para lembrar e descobrir mais algumas façanhas no nosso amigo Netbeans. Vamos a listinha de novo.

Gostei:

  • Ainda vou descobrir alguma coisa.

Não gostei:

  • Set as Main Project. Isso é muito chato!
  • O ‘Fix Imports’ só funciona quando a classe não tem nenhum erro, ou seja, só depois de você acertar tudo que uma geral nos imports poderia fazer.
  • Ainda não descobri um atalho para o Quick&Fix. No Eclipse, CTRL+1.
  • Não dá pra você simplesmente matar, parar, *exterminar* com o serviço do servidor de aplicações que estiver utilizando. No meu caso tem sido péssimo, pois o servidor de aplicações roda localmente na minha estação, mas o banco de dados eu acesso o do escritório (lembre-se que eu trabalho em casa agora :D) via VPN e às vezes demora uns 10 minutos pra verificar todas as conexões. (Nota mental: não que eu queira largar conexões penduradas no banco sempre, mas neste caso seria melhor do que esperar 10 minutos, afinal, em menos de 10 minutos o oracle já iria matar as conexões mesmo).

No final de semana tem mais.