Usando Working Sets no Eclipse

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

eclipse_ativar_working_sets

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

eclipse_visualizando_working_sets

Crie, modifique ou remova qualquer working set.

eclipse_gerenciando_working_sets

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

eclipse_go_into_working_set

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Um exemplo completo com JAAS

Devido ao um dos últimos posts deste blog, sobre utilização de JAAS com JDBC Realm e a grande procura por exemplos mais completos, com login e logout, por exemplo, resolvi melhorar um pouco a aplicação e disponibiliza-la para download.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Autenticação e Autorização: JAAS com JDBC Realm

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

  • Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
  • Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

Continue lendo “Autenticação e Autorização: JAAS com JDBC Realm”

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.