Nascia um novo nicho de mercado: o dos Ambientes Integrados de Desenvolvimento, ou IDEs (Integrated Development Environment).

Transcrição

1 6Entendendo o Ambiente de Desenvolvimento Capítulo 3 Introdução - A breve história do mercado de IDEs Até 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.

2 Capítulo A3 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 infraestrutura 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

3 Entendendo o Ambiente de Desenvolvimento 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 Studio 1, 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.

4 Capítulo A3 Conjunto de plugins Objetivo JBoss Tools WTP JDT Eclipse IDE (Workbench) 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 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. Conjunto de plugins implementados sobre o Workbench, contemplando funções básicas para desenvolvimento Java em geral. 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

5 Entendendo o Ambiente de Desenvolvimento 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 e leitura de artigos e de base de conhecimento (normalmente em seções technical resources ) relacionados ao tema de interesse. o Acesso a 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 JDT e WTP jboss Tools Descrição 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. 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 Tomcat Sysdeo Apache Derby 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. Permite a ativação, desativação, hot-deploy e depuração de execução em ambiente Tomcat. 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.

6 Capítulo A3 Quantum DB Hibernate Console PMD Rhino Javascript Glassfish Polarion SVN MyLyn Permite conexão com diversos SBGD-Rs via JDBC, manipulação de esquemas e dados 1. 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. 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 Plugin que traz recursos para edição e depuração de arquivos Javascript. Plugin para controle do servidor Glassfish. Plugin para operações de trabalho em equipe com o Subversion. 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 plugins padrões da plataforma Eclipse ou daqueles adicionados pelo desenvolvedor.

7 Entendendo o Ambiente de Desenvolvimento 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.

8 Capítulo A3 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 formato 1. 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) 1 Exceto em cópias de avaliação.

9 Entendendo o Ambiente de Desenvolvimento 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 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 retorna 1 : 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 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 . 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 s 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 completa.

10 Capítulo A3 Figura A3.10. Pesquisa por 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 ). Figura A3.12. Listas de pendências do usuário ou equipe associadas ou não a linhas de códigos fontes.

11 Entendendo o Ambiente de Desenvolvimento 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ção 1 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. 1 O 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 acionamentos e explicações, assim como o maestro não toca nenhum instrumento.

12 Capítulo A3 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. Figura A3.17. Projetos de demonstração da aplicação RH Demo, importados para o Eclipse.

13 Entendendo o Ambiente de Desenvolvimento 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 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 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.

14 Capítulo A3 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) 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 Projetos Eclipse resultantes 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 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. Projeto Modelo Expandido para Customização: [jcompany_base]\meus_projetos\

15 Entendendo o Ambiente de Desenvolvimento jcompany_ini_jsf Nome (Opção): Struts Mesmos projetos acima, porém com configurações para tecnologia Struts, e não JSF, no projeto principal. 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 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) 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 Projetos Eclipse resultantes 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. Figura A3.21. Diálogo de criação do projeto rhtutorial.

16 Capítulo A3 17. Informe os seguintes dados no formulário de criação 1 : 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, preenchido 2. 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 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.

17 Entendendo o Ambiente de Desenvolvimento 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 (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. Figura A3.24. Disparo manual do M2Eclipse para sincronia de dependências Maven com o Eclipse.

18 Capítulo A3 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).