Foi lançado ontem a primeira versão do J2EE Spider. Um projeto Open Source brasileiro (por enquanto com um desenvolvedor - Bruno Braga) sobre geração de código Java.
Suas principais preocupações foram com facilidade de uso, integração com o ambiente de desenvolvimento, liberdade para escolher o que deve ser gerado, geração incremental e customização do template de código para se adequar a forma de desenvolvimento de cada equipe. Além disso existem outras preocupações como suportar diversas tecnologias como Struts, JSF, Tapestry, Mentawai, etc… Mas a primeira versão começa pelo básico, que é Struts.
O projeto é novo, começou a ser desenvolvido esse semestre, e alguns vídeos e downloads da primeira versão podem ser acessados abaixo.
Se alguém tiver alguma sugestão, diz ai que eu posso avaliar.
Vou precisar também de pessoas boas para ajudarem com a parte de tecnologia. Template de JSF, Tapestry, etc…
Se alguém tiver interesse, me manda um e-mail.
Muito boa a fundamentação do projeto, o foco das equipes de desenvolvimento devem ser no problema que deve ser resolvido e ferramentas como essa não só facilitam a nossa vida mas permitem que nos preocupemos com outras coisas em relação ao projeto.
Pois é…
A gente tem que parar de perder tempo com tarefas repetitivas e gastar tempo com o que realmente importa, que são as regras de negocio e soluções para o cliente.
Também espero arrumar colaboradores hehe =)
Porque remar sozinho é foda
Eu até gostaria de ajudar… em especial com JSF, que é a minha praia.
Mas eu uso o Netbeans ;), e adoraria ver um módulo assim para ele. Gostei muito da sua idéia, e da maneira como você a desenvolveu. O quão “adaptável” é o seu código?
Acho que talvez você deva focar, num primeiro momento, na portabilidade do seu plugin para Linux (você disse que não testou, mas pode ser que ele já esteja funcionando bem com certas ressalvas, não é?).
E depois, tornar essa solucão independente de IDE ajudaria bastante. Eu não sou familiarizado com o desenvolvimento de módulos para o netbeans, mas se você chamar a atencão da comunidade (e de alguns bons desenvolvedores aqui do próprio GUJ), eles podem te ajudar com isso.
Boa sorte com o projeto, e parabéns pela iniciativa, excelente trabalho =D
É, pois é… Estava até comentando com o Paulo Silveira da Caelum outro dia sobre isso… Como o projeto é OpenSource, seria legal ter a integração também com outras IDEs, como o NetBeans, porque agradaria gregos e troianos.
Mas não pode ser um foco meu agora. Se eu parar para aprender a criar plugins para o NetBeans, o projeto não vai andar. Então nesse momento o meu foto tem que ser no Eclipse que é a maioria, e tenho que fazer o projeto se desenvolver (ter novos recursos).
Se houvesse alguém que tem skill para fazer plugin para o NetBeans ai já é outra conversa. Dava para passar para a pessoa toda a estrutura do projeto e como funciona as coisas, e ela se preocupar somente com a interface visual.
A portabilidade para Linux, já deve estar funcionando enquanto plugin (porque para o eclipse é a mesma coisa). Talvez de algum problema na hora de gerar os arquivos mas nada grave de resolver. Vou reinstalar meu Linux no fim de semana e vou checar isso.
Valeu pela força. Essa é a melhor parte:
Sinal que as coisas estão indo no caminho certo, porque agrada os desenvolvedores.
Em que sentido? Adaptavel para o NetBeans, ou o quanto o código gerado é adaptavel para a sua forma de desenvolvimento?
Parabéns Bruno, o projeto parace ser bastante promissor já que poderemos eliminar tarefas repetitivas no desenvolvimento dos projetos. Tenho algumas dúvidas em relação a funcionalidades autais e futuras pretendidas neste projeto:
1 - Não teremos mais que ficar configurando arquivos xml na mão?
2 - Poderemos adicionar layouts externos ?
3 - O layout será tratado como template ?
4 - Poderemos, através do wizard, relacionar Página + Action + Atributos ?
5 - Qual sua intensão futura, em relação a funcionalidades, deste projeto ?
Parabéns mesmo cara, e boa sorte neste seu desafio !!!
Mais ou menos…
O plugin não vai substituir particularidades das tecnologias, que em alguns casos como Struts e Spring é a configuração via arquivo XML.
Porém quando for startar um novo projeto, esses XMLs vão vir todos configurados e integrados entre as tecnologias que você escolher.
A partir dai o fluxo de desenvolvimento é o seu fluxo normal. Se você editava XML na mão, vai continuar editando para criar novas funcionalidades no sistema. A diferença é que a estrutura inicial foi gerada e você não precisou perder tempo com isso.
Outro ponto é que para o Struts por exemplo, não existe a edição de arquivos XML. O projeto foi gerado com um arquivo xdoclet-build.xml, ele realiza a geração dos arquivos XML do Struts baseado nos artefatos das classes *Action.java
Sim. Com certeza. Aqueles 3 layouts que existem lá são somente exemplos. Eles pertencem ao template de código default. Você pode criar seu proprio template (gerando códigos diferentes) e ter seus layouts, ou simplesmente adicionar novos layouts ao template default. Dentro da pasta do plugin, existe uma pasta templates, lá que podem ser realizadas essas customizações. Porém eu não criei ainda uma documentação para explicar como fazer isso =P… Nas próximas versões esse item deve estar documentado.
Template dentro do site? Veja que a escolha de layouts é um checkbox. Isso porque nada impede de você escolher mais de um layout por sistema. Nesse caso você estaria usando o recurso de skins. A geração do projeto suporta isso e os skins são gerados sem problemas. Porém ele ainda não gera uma interface para trocar esse skin. Mas nada impede que por enquanto você crie essa interface e permita que o usuário troque os skins do site =) Era essa a dúvida?
O que é atributos nesse seu contexto? Você quer na verdade usar alguns recursos aqui que vão estar presentes no CRUD (veja que existe CRUD no plugin, porém com descrição de em breve).
Você poderá escolher os atributos de uma classe POJO de dominio, configurar as validações para cada atributo e o SPIDER vai gerar o CRUD, ou seja, os Actions e páginas para as tarefas de inclusão, alteração, exclusão e pesquisa. Essa parte de CRUD deve sair na versão 0.3.0.
Dominar o mundo!!!
haha… Brincadeira…
Bom, estamos na versão 0.1.0 eu tenho traçado objetivos até a versão 0.3.0. Por alto, na versão 0.2.0 eu queria suportar outras tecnologias, como JSF. E na 0.3.0 suportar CRUD. Mas isso pode ser alterado se eu não conseguir bons desenvolvedores para ajudar no projeto…
Até chegar a versão 0.3.0 eu vejo quais serão os passos seguintes e posso implementar também alguma sugestão de vocês que seja bacana e que agrege ao projeto.
[quote=boaglio]
Parabéns pelo projeto Bruno, alguma opção ao WinMerge para quem usa Linux?[/quote]
Boa pergunta hehe… Não conheço ferramenta de merge para Linux, mas deve ter sim…
Outra coisa… Você programa em Mentawai? Estava precisando de alguém para fazer template de Mentawai para o projeto.
O SPIDER tem esse freio de mão: existem 23018290321 tecnologias. Eu não sei todas. Não sei Mentawai. Não ser Tapestry, etc… Se eu tiver que aprender essas tecnologias para criar os templates, o projeto não vai andar, porque eu vou perder muito tempo com isso e as outras coisas importantes não vão ficar prontas.
Então vou precisar de colaboração das pessoas para criar os templates =)
O velocity já é facil. Então a parte de codificação dele eu acho que é tranquila.
Dá para criar algo para ajudar a gerenciar os arquivos XML que controlam o template. São poucos arquivos XML, mas em todo caso, talvez de para pensar em algo…
Sabia que se desse problema no Linux era na geração dos arquivos (tinha até comentado no tópico antes). Mas não tive como testar ainda…
Bom a sua sugetão fez o path do Windows ficar como /C:/pasta…
Meio estranho, mas eu testei aqui e funcionou no Windows. Então deixei do seu jeito. Se agora funciona no linux otimo =)
Até o inicio da semana que vem vou lançar a v0.1.1 que corrige uns problemas de geração em outro idioma e de carregamento de outros templates de código.
Caso o que eu falei deixe dúvida, sim os arquivos e pastas mudam de nome quando seleciona outro idioma. A pasta apresentacao passa a ser view, modelo passa para model, etc…
