Introdução
- A breve história do mercado de IDEs
A
A
té a década de 80, um desenvolvedor de software típico lidava com uma diversidade de ferramentas para realizar o seu trabalho: editores de códigos fontes, utilitários de compilação e montagem, produtos para depuração e logging, dentre outros. Esta desconexão de ferramentas aceitava e tornava frequente mesmo os erros mais elementares, tais como diretivas e caminhos (paths) inválidos - um mundo nada fácil para iniciantes.Com o advento das interfaces gráficas e popularização das tecnologias Cliente/Servidor na década de 90, começaram a surgir, finalmente, as “aplicações” do desenvolvedor. Fabricantes como Microsoft, Borland e Sybase (PowerSoft) introduziram tais produtos que tomaram de assalto os departamentos de TI por simplificarem o acesso ao resultado e aumentarem a produtividade em geral.
Nascia um novo nicho de mercado: o dos “Ambientes Integrados de Desenvolvimento”, ou IDEs (Integrated Development Environment).
Logo seguidos pela IBM e Oracle, os fabricantes líderes neste segmento disputavam presença nas empresas mantendo um valor médio de licença em torno de U$ 5.000,00 por desenvolvedor (Opções mais baratas estavam disponíveis, mas com restrições técnicas para uso corporativo). Nada mal para estes fornecedores, com o mundo em franca informatização.
Mas com a demanda para desenvolvimento Cliente/Servidor encolhendo no final da década passada, eles tiveram que reposicionar suas IDEs para a tecnologia Java. E o fizeram praticando a mesma base de preços tradicional. Novos players surgiram nesta fase, tais como a BEA, IntelliJ e a própria Sun, de olho em um filão promissor.
Esta disputa entrou pelo século XXI tendo na ferramenta JBuilder da Borland alguns sinais de liderança, seguida pelo JDeveloper da Oracle e pelo WSAD da IBM. Mas as vendas eram ainda pífias. Comunidades do incipiente movimento Open Source começavam a disponibilizar alternativas na forma de editores de código Java com alguma inteligência que, apesar de não serem IDEs competitivas em funcionalidades, tinham na gratuidade apelo suficiente para desacelerar vendas.
Este não seria ainda um advento ameaçador para os fornecedores caso a IBM não houvesse decidido doar o núcleo de seu ambiente de desenvolvimento, o WSAD, para a comunidade Open Source, batizado como “Eclipse Plataform”. O mercado terminou por torná-lo seu ambiente de desenvolvimento
preferencial com mais de 80% de adesão em alguns poucos anos. Estava extinto o recém-criado mercado de IDEs!
Com uma opção de qualidade e gratuita, as empresas puderam utilizar as somas economizadas com a “não aquisição” de IDEs no desenvolvimento de mais projetos e/ou aumento de sua produtividade via aquisição, pelo mesmo custo, de uma solução muito mais abrangente. Por exemplo, englobando
frameworks, geradores de código, metodologias, ferramentas CASE, ambientes para desenvolvimento em equipes etc.
Com seus produtos encalhados, os fabricantes tradicionais tiveram que tomar outros rumos: alguns mantiveram seus produtos para vendas fashion (pela marca), comprando outras empresas para tentar agregar valor à sua opção; outros abriram o código de seus produtos e os doaram para comunidades Open Source, como tentativa de concorrer com o Eclipse... Mas nada disso convenceu o mercado ou alterou o seu market-share.
A breve história do nascimento e ocaso do mercado de IDEs é uma grande demonstração prática do poder e benefícios do movimento OSS (Open Source Software) para as empresas compradoras de TI.
3
6
Entendendo o Ambiente
A IDE Eclipse
- Por que o Eclipse?
O jCompany utiliza o Eclipse como opção principal de IDE, por dois motivos centrais: o Sua larga margem preferencial no mercado, garantindo conhecimento de base
disseminado, pressão e massa crítica para promover a continuidade da iniciativa;
o Sua arquitetura de altíssima flexibilidade, que permitiu à Powerlogic customizar o ambiente de desenvolvimento dotando-o de “conhecimentos do processo e dos frameworks utilizados na arquitetura jCompany”, algo especialmente difícil de se conseguir nas IDEs de gerações anteriores.
o Pelo fato da única alternativa considerável, o Netbeans, ser capitaneada pela ex-Sun, adquirida pela Oracle e de futuro incerto.
Dito isso, é bom comentarmos que nada nos impede de utilizar o framework de integração do jCompany (considerado seu principal componente), seus utilitários Maven e metodologias, em qualquer outra IDE Java, mesmo proprietária.
Mas como os plugins de geração de projeto, mapeamentos e artefatos Java EE não estarão disponíveis, haverá perda de produtividade. Por este motivo, o uso do Eclipse ou de IDEs comerciais baseadas em Eclipse (WSAD, MyEclipse, etc.) são as opções mais recomendadas.
O Eclipse no jCompany
- O Eclipse para desenvolvimento Java EE
A plataforma do Eclipse é composta de vários subsistemas, cada um deles implementados utilizando-se um ou mais plugins, conforme o diagrama da Figura A3.1.
Figura A3.1. Subsistemas da Plataforma Eclipse.
O subsistema primariamente utilizado para desenvolvimento de aplicações é o “Eclipse Workbench” (Bancada de trabalho Eclipse), sobre o qual são construídos plugins para apoio ao desenvolvimento específico, em cada linguagem. Em outras palavras, o Eclipse Workbench em si é uma
infra-estrutura de base que provê funções genéricas de uso comum, em IDEs.
Estas funções trazem modelos genéricos para a criação, edição, gerenciamento e navegação entre recursos em geral, mas desconhecem e não contém especialidades para nenhuma linguagem específica, o que deve ser atendido através de um ou mais plugins especializados, para cada linguagem.
Exemplo: Para desenvolvimento Java, especialmente, a distribuição básica do Eclipse já vem com um conjunto de plugins batizados de JDT (Java Development Tools), que possuem recursos para que editores do Workbench reconheçam a sintaxe Java, exibam marcas de erros apropriadamente, permitam compilação just-in-time etc.
Mas os plugins do JDT não foram criados para desenvolvimento de aplicações Java EE. Eles formam apenas um substrato básico para desenvolvimento em idioma Java, mas não reconhecem de forma
inteligente e suficiente os demais artefatos com seus idiomas próprios, tais como JSP, XML, CSS, Javascript, etc. Por este motivo, para Java EE, outra camada de plugins precisará ser utilizada.
Para este fim, o jCompany homologa os conjuntos de plugins do WTP (Web Tools Project), mantidos pela própria comunidade Eclipse, e do Red Hat Developer Studio1, mantidos pela Red Hat - e que, por sua
vez, são especializações dos plugins WTP.
Para não perdermos o fio da meada, vamos recapitular as nossas “camadas de desenvolvimento Java” no Eclipse:
1 O jCompany utiliza apenas uma parte do total de plugins hoje embalados em conjunto pelo Red Hat, conhecidos como JBoss Tools
(versao Open Source) ou Red Hat Developer Studio - RHDS (versão comercial). Basicamente, o jCompany se vale dos editores de Tiles e JSF/Struts, originalmente criados pela empresa Exadel e adquiridos pelo jBoss Group. Neste livro, será utilizada a sigla RHDS, de forma simplificada, não significando que este produto esteja inteiramente disponível.
Conjunto de plugins Objetivo
JBoss Tools Conjunto de plugins que especializam o WTP para reconhecerem arquivos de configuração de frameworks de uso comum tais como JSF e Hibernate/JPA, além de permitirem algum nível de edição visual em arquivos de markup (xhtml, html, jsp), dentre outros
WTP Conjunto de plugins implementados para
desenvolvimento de Java Enterprise Edition (Java EE), que especializam e adicionam ao JDT o reconhecimento inteligente de artefatos padrões EE tais como arquivos “.jsp”, “.xml”, “.properties”, “web.xml”, além de técnicas de empacotamento (WAR e EAR) e de construção de Web-Services.
JDT Conjunto de plugins implementados sobre o Workbench, contemplando funções básicas para desenvolvimento Java em geral.
Eclipse IDE (Workbench) Framework para construção de ambientes integrados de desenvolvimento para diversos propósitos e linguagens
A Figura A3.2 já foi descrita em detalhes no capítulo introdutório e ilustra a arquitetura de alto nível do ambiente Eclipse, considerando-se as camadas de edição Java EE e também outros plugins “paralelos”, não necessariamente “empilhados” sobre o JDT ou WTP.
Figura A3.2. Arquitetura do ambiente de IDE do jCompany, com base no Eclipse.
Hum... Se o desenvolvedor for um iniciante no mundo Eclipse, já deverá estar percebendo que,
exatamente devido à sua arquitetura excepcionalmente flexível, pode-se demandar um bom tempo para uma compreensão profunda do mesmo em toda sua amplitude.
Felizmente, isso não é necessário em um primeiro momento! Poderemos iniciar imediatamente a sua utilização para o nosso propósito, com boa produtividade, especialmente porque o jCompany vem com um roteiro de utilização que apóia decisivamente os iniciantes, acionando os plugins apropriados através de roteiros "passo a passo" que o conduzem até a obtenção do resultado final para diversas situações comuns.
- Aprendendo mais sobre o Eclipse
Neste livro, iremos percorrer várias funções do Eclipse, e terminaremos por adquirir conhecimentos básicos a seu respeito. O conceito de “Perspectivas”, criação de projetos e editores dos diversos plugins, acionamento de rotinas externas, depuração e diversas dicas práticas serão vistos nos tutoriais que se seguem.
Mas seria de grande inocência considerar este conhecimento suficiente para livrar o desenvolvedor de todos os problemas que irão surgir em seus projetos reais. Em algum momento, deve-se dedicar tempo
para aprofundamento na IDE Eclipse e seus plugins - são inúmeras as técnicas e recursos de produtividade à disposição, que fogem ao foco central deste livro.
Para esta finalidade, sugerimos os seguintes passos e recursos:
o Acionamento do menu “Help – Welcome”, leitura e execução dos tutoriais.
o Acesso ao www.eclipse.org e leitura de artigos e de base de conhecimento (normalmente em seções “technical resources”) relacionados ao tema de interesse.
o Acesso a www.eclipse.org/home/categories/enterprise.php e inscrição nos “Newsgroups” ou “maillists” (BIRT e WTP, no mínimo).
Figura A3.3. Acionando o menu “Overview” para obtenção de ajuda no Eclipse.
- Os plugins homologados pelo jCompany
Além do conjunto de plugins “JDT e WTP” que podemos considerar quase “padrões” para
desenvolvimento Java EE em ambiente Eclipse, existem diversos outros plugins Open Source de terceiros que são homologados pelo jCompany, visando maximizar a produtividade do desenvolvedor, para não falar dos plugins próprios.
No que se refere aos plugins de terceiros, o trabalho realizado pela Powerlogic no jCompany envolve prospecção, testes integrados com os demais plugins e definição de seu papel junto ao processo de construção Java EE como um todo. A instalação e configuração integradas também são benefícios que estão debaixo do conceito de “homologação” do jCompany, que traz para si a responsabilidade de atualizá-los, ao longo do tempo, eliminando esforço de “controle de versões e configurações”, neste âmbito.
Confira a relação de todos os plugins Eclipse homologados no jCompany:
Plugins Homologados Descrição
JDT e WTP Já citados, são considerados parte do “núcleo” Eclipse, do ponto de vista do jCompany, e atualizados sempre em conjunto com atualizações de versão do próprio Eclipse em si.
jBoss Tools 3.0.0 Como citado, complementam o suporte principal do desenvolvimento especializando o WTP para que reconheça arquivos de configuração de frameworks de uso comum tais como Struts, JSF, Tiles, Hibernate e JPA, edição visual de arquivos (.jsp), dentre outros.
Importante: o jCompany traz configurações especiais e refinadas nestes plugins, para permitir edições visuais de JSPs contendo Tags próprias do jCompany, bem como das Tags Apache Trinidad. Eclipse BIRT Conjunto de plugins mantidos pela empresa Actuate para confecção
de relatórios WYSIWYG sofisticados, podendo incluir gráficos, quebras e totalizações, exportação de dados e geração em vários formatos.
Tomcat Sysdeo Permite a ativação, desativação, hot-deploy e depuração de execução em ambiente Tomcat.
Apache Derby Permite a criação de um serviço de banco de dados local, no escopo do projeto, rapidamente acionável e que permite desenvolvimentos sem acesso à rede, para prototipações ou garantia de portabilidade.
Quantum DB Permite conexão com diversos SBGD-Rs via JDBC, manipulação de esquemas e dados1.
Hibernate Console Permite a configuração de uma fábrica Hibernate local para testes e codificação assistida de HQL. Verifica também a sintaxe dos HQLs embutidos em códigos Java, dentre outros recursos.
PMD Este plugin permite verificação de código de maneira estática, podendo apresentar erros de compilação para codificações fora do padrão. O jCompany não realiza customizações nem o ativa como padrão para os projetos criados. Uma utilização mais sofisticada deste plugin é realizada pelo produto jCompany QA
Rhino Javascript Plugin que traz recursos para edição e depuração de arquivos Javascript.
Glassfish Plugin para controle do servidor Glassfish.
Polarion SVN Plugin para operações de trabalho em equipe com o Subversion. MyLyn Plug-in para integração com ambiente de Gerenciamento de
Requisitos, podendo ser utilizado de forma básica (como vem no jCompany) ou especializado pelo eCompany Process Suite, quando o desenvolvedor utiliza o Powerlogic jALM.
Figura A3.4. Diretório separado de instalação de plugins homologados.
- Os plugins próprios do jCompany
O máximo resultado de produtividade que uma IDE de desenvolvimento pode dar somente é alcançado quando esta ferramenta passa a “conhecer efetivamente os padrões de arquitetura e do
processo de construção” sendo utilizados.
Este é um cenário de produtividade excepcional, mas bastante raro. Na prática, antes do Eclipse, pouco se customizava no nível das IDEs. Mesmo com o Eclipse, a quase totalidade dos plugins existentes não pode pressupor o uso de uma arquitetura X ou padrão Y ficando, portanto, bastante limitados quanto ao poder e abrangência potenciais quando comparados à solução integrada do jCompany.
É neste cenário que entram os plugins de criação do módulo jCompany IDE, chamados de “jCompany
Artifact Generator”. Eles trazem diversos assistentes de criação que conduzem o desenvolvedor pelos
passos iniciais de construção da 1ª versão de todos os artefatos envolvidos em Casos de Uso padrões da sua metodologia e imediatamente ajustados à arquitetura do framework de integração.
Após esta criação inicial, roteiros da metodologia automatizados via “folhas de apontamentos” (Cheat-Sheets) do Eclipse comandam a edição de cada um dos artefatos gerados pelos plugins jCompany, em editores mais apropriados para modificações e complementações livres.
1 Estes plugins são instalados separadamente no diretório “[jcompany_base]\eclipse\pluginsPlc”,. Deste modo, ficam separados de
Assim, trabalhamos com duas categorias de plugins:
o Os “plugins de processo” para obtenção de uma primeira versão da solução pretendida,
segundo os padrões, arquitetura e metodologia definidos.
Esta categoria de plugins pressupõe o uso de determinada arquitetura, no caso, a provida pelo jCompany
FS Framework. Note que estes plugins não seriam de serventia, isolados do framework, por exemplo -
mas são excepcionalmente melhores para a produção de uma primeira versão de resultado que siga “melhores práticas”.
o Os “plugins de edição” genéricos, para complementação e ajustes livres que se façam
necessários, a partir daí.
O seu propósito é bem distinto do primeiro: permitirem uma elaboração flexível e livre do que quer que se faça necessário ajustar, nos vários formatos de artefatos Java EE, e com flexibilidade exigida por especificidades de cada Caso de Uso. Esta categoria de plugin é mais comum no mercado - o jCompany, como já vimos, reutiliza para este fim os plugins WTP e da Red Hat.
Figura A3.5. Plugin de processo do jCompany, gerando primeira versão de arquivos
Figura A3.6. Plugin de edição WYSIWYG do jBoss Tools, especializado em modificações de forms XHTML.
Os plugins do jCompany são mantidos em subdiretório distinto, abaixo de
“[jcompany_base]\pluginsPlc\powerlogic”, deste modo mantendo-os segmentados em diretórios distintos dos plugins genéricos do Eclipse e também dos plugins homologados de terceiros.
Figura A3.7. Diretório de instalação dos plugins de processo do jCompany (jCompany Artifact Generator)
- Metodologia de construção Java EE - Documentação on-line integrada (Tutorial)
A Ajuda (Help) On-line do Eclipse é um outro subsistema da plataforma Eclipse também extensível, aceitando documentações de plugins complementares às pré-configuradas. Tais documentações também compartilham de algumas vantagens em comum oferecidas por este subsistema, tais como índice
unificado e busca textual.
Mas o jCompany faz uma utilização bastante interessante da Ajuda On-Line do Eclipse, ao
disponibilizar toda a documentação da metodologia e base de conhecimento do suporte Powerlogic disponível neste formato1. Deste modo, o desenvolvedor possui acesso via busca textual
a quaisquer informações desde padrões e práticas de construção recomendados, até dúvidas frequentes respondidas.
Aprender a utilizar bem a Ajuda On-Line é como “aprender a pescar” conhecimentos. Vamos, portanto, exercitar um pouco este acesso configurando a Ajuda On-line para nos permitir uma busca textual restrita à metodologia e base de conhecimento do jCompany, e fazendo uma pesquisa-modelo: 1. Acione o menu “Help -> Help Contents”
2. Na página principal do Help On-Line, clique em “Search Scope”. No diálogo “New Search List”, digite “Powerlogic” em “List name” e selecione o tópico “Powerlogic jCompany” na lista, desmarcando o item "Deprecated" (para não indexar conteúdo antigo)
Figura A3.8. Configuração de filtro para busca textual, sem conteúdo deprecated (depreciado, antigo)
3. Selecione o filtro da busca somente para jCompany no diálogo “Select Search Scope”.
Figura A3.9. Seleção de filtro para que fique corrente (default).
4. Teste a busca restrita, digitando “email” no campo “Search”. Deve-se reparar que não somente aparecerão os vários capítulos onde ocorra o termo, mas que estarão ordenados por número de ocorrências e com o termo em destaque à direita.
Em nossa instalação, esta busca específica retorna1:
o Primeiro o Apêndice D - “Exemplos de Código de Implementação”, contendo exemplos típicos de codificação.
o Em segundo o Apêndice E – “Roteiro de utilização do jMonitor”, já que um email pode ser enviado no jCompany através de appenders do Log4j que enviam mensagens JMS e delegam este serviço para o jCompany Monitor.
o O terceiro capítulo retornado é o “B.6.2 Regras de Negócio – Validação de Entrada”, porque contém referências sobre como validar o formato de um campo do tipo “email”.
o O quarto capítulo é o “B.6.4. Fluxo de Aprovação. Exclusão Lógica e
Versionamento/Auditoria”, porque contém explicações sobre como enviar e-mails ações de reprovação para lógicas de workflow.
5. E assim por diante, seguindo por capítulos de menor relevância.
1 O resultado pode depender da versão (e release) utilizada. Cópias de avaliação, por exemplo, podem não conter a documentação
Figura A3.10. Pesquisa por ‘email’ retornando capítulos da metodologia e base de conhecimento
6. Eventualmente, como os capítulos de documentação do jCompany são extensos, não se encontrará os termos em destaque facilmente. Por este motivo, uma boa prática é sempre repetir a consulta
utilizando-se “control+F” sobre o texto do capítulo.
Figura A3.11. Pesquisa com Control+F dentro do capítulo para achar termos.
- Metodologia de construção Java EE - Roteiros “Cheat-Sheets”
Os métodos e padrões de construção Java EE, além de base de conhecimento, disponíveis na Ajuda On-Line da IDE, como vimos, são realmente de grande auxílio à produtividade no dia a dia para situações de dúvidas adversas, quando bem utilizadas.
Porém, para melhor conduzir o desenvolvedor pela implementação padrão para Casos de Uso típicos previstos na metodologia, o jCompany utiliza um recurso ainda mais apropriado do Eclipse: as folhas
de Apontamento ou “Cheat-Sheets".
Os Cheat-Sheets, ao contrário de sua “aparência inicial”, podem ser confundidos com as listas de tarefas (TO DO Lists), mas são mais que isso.
Vejamos do que se tratam estas listas de tarefas simples que também estão presentes na IDE Eclipse, antes de entender os Cheat-Sheets.
7. A visão de “Tasks” (Tarefas pendentes do usuário ou equipe) pode ser ativada, se já não estiver, através da opção de menu “Windows -> Show View -> Tasks” (se não existir a opção Tasks, entre em “Others” e procure na categoria “General”).
8. Novas tarefas podem ser criadas a partir de opção da visão, como na figura A3.10, ou simplesmente comentando-se dentro de códigos fontes com determinados prefixos padrões, tais como “TODO”, “FIXME” e outros que podem ser definidos.
Já os Cheat-Sheets têm um objetivo bem distinto das Tasks, que é o de “orquestração1” do processo
de desenvolvimento. Os Cheat-Sheets são definidos através de roteiros com ações de desenvolvimento
que podem, em cada passo, acionar um plugin distinto. Deste modo, após uma sequência de passos discretos, o desenvolvedor pode produzir um resultado complexo, tal como a produção de um Caso de Uso, passando por dez ou mais plugins distintos, ao todo.
Vamos conhecer o funcionamento de um Cheat-Sheet no próximo tópico, importando e liberando a aplicação de exemplo “rhdemo”.
- Aprendendo com o Exemplo RH Demo
Uma das formas mais rápidas de se aprender coisas complexas (como técnicas de desenvolvimento de sistemas ou tocar um instrumento musical) é através de exploração prática e bons exemplos. Um bom exemplo disponível pode valer mais que muitas páginas de teoria!
Por este motivo, julgamos essencial que desenvolvedores, especialmente iniciantes em um novo paradigma de desenvolvimento, tenham em mãos - no mínimo - um bom exemplo funcionando para comparações e estudo. No jCompany, este exemplo é disponibilizado através da aplicação “rhdemo”. Neste livro, iremos construir uma aplicação similar (mas não igual) à "RH Demo", chamada “RH Tutorial” (rhtutorial). Sugerimos que, a partir daí, o desenvolvedor mantenha no mínimo estas duas aplicações sempre disponíveis em sua IDE Eclipse para rápidas prospecções.
Vamos então configurar a aplicação “rhdemo” e deixá-la funcional, aproveitando para aprendermos a utilização dos Cheat-Sheets do jCompany:
9. Acesse o item de menu “Help -> Cheat-Sheets”.
10. Selecione o roteiro “Importar o projeto RHDEMO” do conjunto de roteiros do jCompany.
Figura A3.13. Acionamento do roteiro de importação do projeto RHDEMO.
11. Siga agora as instruções de cada passo do roteiro, clicando em “Click to Complete” em seguida ou conforme orientação da documentação do passo.
1O conceito de “orquestrador” reside do fato de que, de forma similar ao “maestro” conduz a sua orquestra, os Cheat-Sheets
conduzem o desenvolvedor para executar a atividade certa, na ordem certa e chamando o plugin correto (mais apropriado para a ação, segundo o processo). Mas os roteiros do Cheat-Sheets em si não contém e nem executam nenhuma ação que não seja de
Figura A3.14. Roteiro com instruções passo a passo.
Figura A3.15. Opção de importação de projetos existentes para a Workspace.
Figura A3.16. Em "meus_projetos", selecionar somente projetos rhdemofcls*.
12. Ao final, os projetos rhdemofcls, rhdemojsf ou rhdemo (conforme a tecnologia desejada seja JSF/Facelets, JSF/JSP-Tiles ou Struts, respectivamente) devem estar disponíveis no ambiente Eclipse e visíveis na visão “Package Explorer” do Eclipse.
13. Agora vamos acionar um segundo roteiro dos Cheat-Sheets, chamado “Executando o RH Demo”. Certifique-se de estar com o projeto rhdemofcls (ou variações) selecionado e siga as instruções do roteiro.
Importante: Não iremos redundar as instruções do roteiro neste livro, mas seguem abaixo algumas dicas
e exemplos de ações chave no processo, para conferência:
o Não modifique o arquivo de configuração de pool, já que vamos utilizar o SGBD-R Apache Derby, para o qual a configuração já está pronta.
o Para ativar o SGBD-R Apache Derby (que já vem pré-configurado e disponível para cada projeto, como iremos ver mais em detalhes em capítulos subsequentes), clique direto no projeto e, em seguida, em “Apache Derby -> Start Derby Network Server”.
Figura A3.18. Serviço Derby ativo, com item de menu e mensagem de iniciação em destaque.
o Acione o Tomcat somente após o Derby estar ativo, através do ícone do gato (Tomcat Sysdeo), e verifique se as últimas mensagens de log na janela console contêm a porta do serviço “Starting coyote HTTP / 1.1 on http:8080” e o indicador de inicialização correta, “Server startup...”. Estes são sinais de sucesso na ativação do serviço.
Figura A3.19. Serviço Tomcat ativo, com indicadores em destaque.
14. Execute a aplicação abrindo qualquer navegador e digitando http://localhost:8080/rhdemofcls, com usuário senha “admin -> senha”. Mais adiante, no módulo B, iremos compreender as configurações do Tomcat e da segurança em mais detalhes.
Figura A3.20. Página principal da aplicação “rhdemofcls”
15. Navegue pelas opções da aplicação para obter uma impressão geral sobre padrões de interface e aparência dos Casos de Uso disponibilizados. Iremos desenvolver uma aplicação similar neste livro, do zero absoluto!
Criando novos projetos de desenvolvimento
- Entendendo as modalidades de projeto
O jCompany vem com um plugin Eclipse próprio para criação de projetos capaz de criar diversos projetos Eclipse simultaneamente para uma separação MVC mais rigorosa. Além disso, ele realiza
diversas configurações logo de saída, incluindo configurações de “Class Path”, “Source Folders”, etc. Tudo isso pode ser customizável editando-se os projetos Eclipse de modelo (template) que possuem o nome “ini”, tal como “jcompany_ini_jsf”. Chamaremos estes projetos de “template INI”.
Importante: Através da customização destes templates para o contexto específico da empresa -
inserindo preferências via camada Bridge ou dentro do próprio projeto modelo - novas aplicações geradas pelo plugin de projeto já virão com aparência, logotipo, leiautes, menus e configurações específicas do negócio. Estas técnicas serão cobertas somente no Volume II desta série (Tópicos Avançados).
Neste capítulo iremos criar projetos utilizando um dos modelos pré-definidos para JSF dentre os modelos pré-existentes no jCompany. Estes modelos são descritos abaixo:
Projetos que Enfatizam as Camadas MVC: Devem ser utilizados para reforçar as camadas MVC e
quando não existirem duas tecnologias para camada Visão ou Persistência, por exemplo. Estes modelos também facilitam a distribuição entre equipes diferentes, onde cada uma se especializa em uma camada (Ex.: Equipe A com Visão/Controle e Equipe B com Modelo/Persistência).
Modelo (template) Projetos Eclipse resultantes
Nome (Opção): JSF (Facelets)
o Arquivo Modelo: [jcompany_base]\meus_projetos\ jcompany_ini_facelets.zip
o Projeto Modelo Expandido para Customização: o [jcompany_base]\meus_projetos\
jcompany_ini_facelets
Cria 3 projetos Eclipse de acordo com arquitetura MVC: o [nome do projeto]: Projeto “principal”, contendo artefatos para camadas Visão e Controle.
o [nome do projeto]_modelo: Contém artefatos para camadas Modelo (Serviços) e Persistência.
o [nome_do_projeto]_comuns: Contém artefatos para camada de Domínio (Entidades) e Interfaces de Fachada, comuns a todas as camadas MVC. Nome (Opção): JSF (JSP + Tiles)
Arquivo Modelo: [jcompany_base]\meus_projetos\ jcompany_ini_jsf.zip
Projeto Modelo Expandido para Customização: [jcompany_base]\meus_projetos\
Mesmos projetos acima, porém com configurações para tecnologia JSF utilizando JSF e JSP/Tiles em lugar de JSF e Facelets, no projeto principal.
jcompany_ini_jsf Nome (Opção): Struts
o Arquivo Modelo: [jcompany_base]\meus_projetos\ jcompany_ini_struts.zip
o Projeto Modelo Expandido para Customização: o [jcompany_base]\meus_projetos\
jcompany_ini_struts
Mesmos projetos acima, porém com configurações para tecnologia Struts, e não JSF, no projeto principal.
Projetos Simplificados: Devem ser utilizado para sistemas mais simples, pois todas as camadas
residem em um único projeto. Também está restrito à tecnologia Struts, não mais recomendada para novos projetos.
Obs.: Note que é possível criar-se templates próprios "JSF Simples", para sistemas pequenos, digamos, que envolvam dez ou menos Casos de Uso. Deste modo evita-se proliferação de projetos de
desenvolvimento para estes casos. É também importante nontar que é plenamente possível se trabalhar rigorosamente dentro das exigências de separações de camada, dentro de um mesmo projeto de desenvolvimento, desde que haja consciência e disciplina por parte do desenvolvedor.
Modelo (template) Projetos Eclipse resultantes
o Nome (Opção): Struts Simples
Arquivo Modelo: [jcompany_base]\meus_projetos\ jcompany_ini.zip
Projeto Modelo Expandido para Customização: o [jcompany_base]\meus_projetos\ jcompany_ini
Cria 1 (um) projeto Eclipse, contendo todas as camadas MVC separadas por pacotes:
o [nome do projeto]: Projeto “principal”, contendo artefatos para todas as camadas Visão, Controle, Modelo, Persistência e Comuns.
Um melhor entendimento sobre a arquitetura de desenvolvimento MVC sugerida pelo jCompany será obtido no próximo capítulo. Por hora, vamos criar um projeto inicial que utilizaremos nos tutoriais deste livro, que prosseguem a partir do módulo B.
- Criando o projeto JSF “rhtutorial” (Tutorial)
No estágio atual recomendamos JSF [Facelets] como opção principal de tecnologia para camada Controle, o que significa JSF 1.2 com XHTML/Facelets no jCompany Developer Suite 5.5.x ou JSF 2.0
(XHTML/Facelets são embutidos neste padrão) no jCompany Develore Suite 6.0. Veja que o jCompany também suporta Struts 1.1.x e JSF 1.2 com JSP/Tiles.
Vamos criar nosso projeto JSF, através do roteiro de Cheat-Sheet em “Help -> Cheat-Sheet” chamado “Criando um novo projeto”.
16. Siga as instruções do roteiro, lendo os textos disponíveis em cada passo do tutorial Cheat-Sheet.
17. Informe os seguintes dados no formulário de criação1:
Project Name: rhtutorial
Directory: [deixar o padrão sugerido] Pacote Base: com.empresa.rhtutorial Modelo do Projeto: Selecionar JSF[Facelets]
Figura A3.22. Diálogo de criação do projeto “rhtutorial”, preenchido2.
E clique em “Finish”3.
Obs.: Aguarde alguns instantes (30 segundos a alguns minutos, dependendo da capacidade e
configurações da máquina) para os três projetos envolvidos serem criados. Pode ser que os
projetos sejam criados inicialmente com erro de dependências, o que será resolvido com a primeira liberação completa pelo M2Eclipse, plugin homologado que sincroniza dependências Maven
(expressa nos arquivos pom*.xml) e do Eclipse.
18. O roteiro abrirá, nos passos seguintes, arquivos de configuração chaves para o desenvolvimento Java EE, a saber:
o Arquivo de configuração de contexto da aplicação no Tomcat, incluindo definição de um pool de conexões JDBC no padrão DBCP. No caso, o “projeto modelo” que vem com o jCompany traz configuração para acesso ao Apache Derby, que é o que utilizaremos neste tutorial. Este arquivo deve ser customizado para o SGBD-R preferencial da empresa em um cenário real.
Deve-se notar que o nome da instância do banco padrão utilizada é “bancolocal” e que o jCompany já inclui uma opção “create=true’ ao final da url de conexão, o que facilitará a criação “em pleno vôo” das tabelas no SGBD-R Apache Derby, como veremos.
1 Repare que, na instalação do Eclipse padrão, o idioma "em inglês" irá por vezes se misturar com extensões e plugins "em português".
Apesar de ser um problema menor, pode-se minimizar estas diferenças instalando-se o pacote de idioma do eclipse para português. De qualquer modo, como grande parte dos plugins não trazem as traduções para português, o problema não fica totalmente solucionado.
2 Importante: Se receber uma mensagem solicitando a apresentação da licença de uso, vá ao site da Powerlogic e se registre para
receber uma licença de demonstração. O processo é rápido e todo automatizado - após um cadastro básico, um e-mail lhe será enviado com um arquivo em anexo para ser incluído no diretório raiz do jCompany. Com isso, o uso fica liberado.
3 Se ocorrer um erro ao usar o nome rhtutorial (porque o projeto “rhtutorial” já existe abaixo do diretório “meus_projetos”), renomeie o
projeto existente para “rhtutorialplc” ou use um outro nome no novo projeto, como “rhtutorial2”. Isto é necessário porque, em alguns releases de demonstração, o projeto “rhtutorial” contendo a aplicação desenvolvida neste livro já vem configurado com este nome.
Figura A3.23. Arquivo de configuração de pool JDBC padrão para o Tomcat (DBCP).
o Arquivos de configuração do Maven. O roteiro irá abrir para conferência os arquivos de configuração do Maven gerados, conhecidos como POM (Project Object Model).
Obs.: O jCompany utiliza um arquivo chamado “projeto-pom.xml” para o projeto como um todo e um arquivo “pom.xml” para cada módulo. Entenderemos as dependências Maven definidas oportunamente. Por enquanto, não são recomendadas modificações.
Importante: Note que os projetos são criados com erros no Eclipse (erros também podem
aparecer ao se editar os arquivos Maven da primeira vez). Após uma liberação completa, no entanto, estes poderão ser resolvidos pelo M2Eclipse.
19. É importante que se execute uma liberação completa desta aplicação para o Tomcat, tal como fizemos com a aplicação “Rh Demo”, a fim de se atualizar as dependências entre Eclipse e repositório Maven e conferir se o esqueleto geral do projeto está correto. Para tanto, basta seguir as orientações de liberação do roteiro Cheat-Sheet e conferir se a página principal da aplicação abre no Tomcat, agora com o endereço http://localhost:8080/rhtutorial. (Utilize o mesmo usuário e senha “admin” e “senha” utilizados no “rhdemo”).
20. Após a liberação com sucesso, selecione todos os projetos com erro e clique direito, em seguida em "M2 Maven -> Update Dependencies". O M2Eclipse irá então sincronizar uma primeira vez e manter, a partir daí, qualquer alteração nos arquivos "projeto-pom.xml ou pom.xml" síncronas com o Build Path do Eclipse.
Sumário
Neste capítulo, discutimos a importância da IDE Eclipse, incluindo os benefícios que trouxe para o mercado com a eliminação de custos de aquisição neste segmento e também seus méritos técnicos que permitiram a criação do ferramental customizado no jCompany, totalmente pré-configurado e instalável em um único acionamento.
Discutimos ainda sobre como o jCompany especializa o Eclipse, trazendo: plugins Open Source homologados de terceiros e plugins Open Source próprios, além de documentação e roteiros Cheat-Sheets de sua metodologia de construção integrados a IDE.
Aprendemos a explorar a busca textual da Ajuda On-Line e a operação básica de Cheat-Sheets, criando nosso projeto “rhtutorial”, que será utilizado durante os capítulos subsequentes.
No capítulo 4 iremos compreender a fundo a arquitetura dos projetos gerados, tanto do ponto de vista de estruturação interna (pacotes, classes e artefatos padrões), quanto externa (dependências e visão geral da arquitetura MVC).
