| Autor |
Mensagem |
|
|
A versão 1.0.0-M3 tem quase o dobro de melhorias do que a versão M2 teve em relação a M1.
Entre elas vale destacar que o plug-in para o Eclipse é distribuído usando o Eclipse Update Site (solicitado aqui no GUJ):
http://www.j2eespider.org/update
ou
http://www.j2eespider.org/update/nightly
E o template é distribuído em um zip separado e você pode descompactá-lo em qualquer lugar do PC.
Mais detalhes sobre como fazer download em: http://www.j2eespider.org/cnf/display/PT/Download
Para quem não conhece o projeto ou quer ver um passo a passo de como utilizar, acesse a sessão de "Getting Started" que é nova:
http://www.j2eespider.org/cnf/pages/viewpage.action?pageId=2326590
E é claro não deixe de perguntar as dúvidas aqui no GUJ e ler materias sobre o projeto como a do InfoQ em março:
http://www.infoq.com/news/2008/03/J2EE-Spider
Segue o changelog da nova versão:
-------------------------------------------
Version 1.0.0-M3 (2008-05-25)
Others Release Notes
** Bug
* [Template] - Acertos no template para Struts - cruds com campo date, javascripts e outros.
* [Template] - Resolvido problema na geração da pasta /jsp/velocity usada para o struts-menu.
* [Plugin - Core] - Quando algum package tinha o mesmo nome do projeto o mapping gerava as classes na pasta errada.
** Improvement
* [Plugin - Core] - Distribuição do plug-in usando jar e em arquivo separado do template.
* [Plugin - Core] - Adicionada validação de compatibilidade entre o template e o plug-in.
* [Plugin - Core] - Criação de aba exclusiva para gerenciar templates.
* [Plugin - Core] - Melhoria de performance do build.
* [Plugin - Core] - Adicionado botão para selecionar todos os atributos de uma classe no CRUD.
* [Plugin - UI] - Novo wizard para abrir o SPIDER Editor.
* [Template] - Mais traduções para o i18n do projeto.
* [Template] - Criado atributos para armazenar um resumo das características de cada template.
* [Template] - Adicionado ao template a possibilidade de executar scripts ant para completar o build.
* [Template] - Utilização da feature de executar scripts ant para rodar o xdoclet-build.xml após a geração de CRUDs com Struts.
* [Template] - Alinhamento do código HTML das páginas jsp geradas.
* [Others] - Utilização do Atlassian Bamboo como software de integração contínua e do Fisheye.
* [Others] - Criado um Eclipse Update Site para instalação e atualização do plug-in.
* [Documentation] - Site: tradução de mais páginas para o idioma inglês (mais documentação).
* [Documentation] - Nova sessão "Getting Started" no site.
-------------------------------------------
Todo mundo que está usando a ferramenta tem achado bastante produtiva. Experimente você também!
Se for um pouquinho curioso, verifique a estrutura do template (que está sendo distribuído separado do plug-in) e tente colaborar para melhorá-lo usando somente os seus conhecimentos de JEE! (não precisa saber de plug-ins para o eclipse ou swt).
|
 |
|
|
parabéns pela iniciativa!
se a maioria das empresas fossem como a Caelum...
abraços,
|
|
|
|
Mas é correto dizer que ele é mais um Application Server ou que ele é uma "camada" ou gerenciador de deploy (baseado em OSGI) entre você e um Application Server que você já conhece (no caso Tomcat)?
Independente do que ele é hoje, acho que se for para o caminho de concorrer com outros AS pode não dar muito certo... Mas se ele for direcionado como um "add-on" para vários AS existentes adicionando os recursos de OSGI, pode ser interessante... eles vão ganhar usuários e maturidade antes que outros projetos tenham algo parecido.
|
|
|
|
wmitsuda wrote:
Pois é. Dando uma olhada por cima (no .zip), vejo que vc costuma exportar o plugin pelo método antigo, onde o plugin é um diretório c/ as suas coisas dentro. Isso não é a forma recomendada faz muito tempo. Se vc reparar, os plugins do Eclipse são quase que na totalidade exportados como .jars, sendo 1 jar por plugin. É mais eficiente armazenar 1 jar no seu HD do que diretórios com um monte de arquivos pequenos.
Na verdade olhando meu Eclipse 3.3.1.1 eu tenho 171 plug-ins que ainda são diretórios, entre eles projetos como JBoss Tools e Subversion.
Mas no caso do SPIDER nem é por opção, é por necessidade mesmo..., como eu disse preciso do path dos arquivos do template :/
Mas nda impede que eu distribua o plug-in por jar e só o template de outra forma...
wmitsuda wrote:
Os templates que vc se refere são os .vm do velocity? Eu presumo que eles estão hard-coded no plugin. Eu acho que vc poderia colocá-los em algum lugar do classpath do plugin (debaixo do /src) e pegá-los via getResourceAsStream(), não?
Template é o conjunto dos arquivos velocity + configurações + jars + arquivos estáticos, etc...
Não estão hard-coded... Mas tem que ser uma pasta... tanto que você pode copiar a pasta do template, colocar no c:\template e no plug-in falar que agora ela está no c:\... então o que vale é o caminho no filesystem...
Se eu colocar os templates dentro do src eu perco a flexibilidade da pessoa tem um outro repositório de templates dela, tipo c:\meusTemplates mesmo ou \\server\templates
o update e os jars iam atrapalhar isso... então tenho q arrumar uma solução para isso primeiro
|
|
|
|
vlw djemacao... é muita coisa para fazer sozinho, mas ta ficando bacana.
Inclusive, eu estou precisando de ajuda em 2 pontos:
- um para terminar os templates, inclusive de JSF
- outro para traduzir a documentação para inglês... o site em português tem mais coisa do q o inglês e eu não to conseguindo dar vazão a isso...
wmitsuda wrote:Bruno, vc poderia quebrar o plugin em extensões, por exemplo, se o usuário não tem a intenção de usar mentawai, não precisaria baixar o respectivo template e seus jars.
Isso poderia diminuir um pouco o tamanho do download.
E daria a chance p/ plugins de terceiros plugarem templates novos no seu plugin.
Tenho que fazer isso também com o plug-in em si.
Até a versão 1.0.0-M1 era 1 plug-in com tudo.
Agora na 1.0.0-M2 se reparar são 2 plug-ins, o que tinha antes e mais um de wizard que é onde fica o wizard de importação.
Então eu tenho que dividir isso em mais plug-ins... separar em plug-in de ui, core, doc, etc...
Um desses passos pode ser esse mesmo de dividir a distribuição do template default em vários plug-in.... mas mesmo assim não ia ajuda tanto porque o menta é menos de 1 MB pro exemplo... a pessoa ia deixar de baixar 20 MB para baixar 15 MB por exemplo... então tenho que fazer uns testes pra ver a viabilidade.
Uma coisa que eu vi agora do update é que cada plug-in é um jar, então trafegar poucos arquivos facilita... não é arquivo por arquivo. Mas ao mesmo tempo isso gera um problema: o template tinha que ser uma pasta no filesystem, não poder ser um jar porque eu preciso do path dos arquivos... :/
|
|
|
|
wmitsuda wrote:Parabéns pelo projeto. Mas um update site não seria nada mal... (abri um bug no Jira p/ isso).
Update usando o próprio Eclipse né?
Na verdade até tem o código para isso no SVN..., o problema é que são 20 MB para baixar arquivo por arquivo, depois vou ver se o desempenho fica bom... O problema não é só o plug-in, tem o template, ele que é grande.
Além disso deixaria de ter as estatísticas de quantas pessoas baixaram do sourceforge... (é uma bobeira útil). Mas vou ver o que eu faço...
|
|
|
|
2EE Spider é uma ferramenta open source para desenvolvimento rápido de aplicações web.
Para mais detalhes e referências veja essa matéria no InfoQ:
http://www.infoq.com/news/2008/03/J2EE-Spider
Essa nova versão corrige problemas e trás novas features.
Se você tem versões antigas é recomendável que atualize para a versão 1.0.0-M2.
O problema de dependência do Java 6 e mapeamento foram resolvidos e agora o build possui log.
Também foi adicionado suporte ao Eclipse 3.4.
Release 1.0.0-M2 changelog:
-------------------------------------------
Others Release Notes
** Bug
* [Plugin - Core] - Problema de dependência do Java 6 - o requisito é Java 5.
* [Plugin - Core] - Um bug no build não estava incluindo os jars do ant usados para o mapping.
** Improvement
* [Plugin - Core] - Suporte ao Eclipse 3.4.
* [Plugin - Core] - Setas para ordenar os campos do CRUD.
* [Plugin - Core] - Adicionada verificação de plug-ins instalados no Eclipse. Cada template de código pode ter uma lista diferente de plug-ins requeridos.
* [Plugin - Core] - Adicionado wizard para importação de configurações do SPIDER a partir de outro projeto.
* [Plugin - UI] - Melhoria no resultado do build mapping.
* [Plugin - UI] - Adicionada opção de detalhes (log) para todos os builds.
* [Documentation] - Novo site: http://www.j2eespider.org
-------------------------------------------
Novo site:
Entre as versões 1.0.0-M1 e1.0.0-M2 criamos um novo site. Ele não está totalmente pronto ainda, mas é muito melhor do que o antigo:
http://www.j2eespider.org
|
|
|
|
pcalcado wrote:Por favor spearam a discussão software livre x proprietário de geração de código. Tem gente que tem gerador de código proprietário que possui código aberto para seus clientes.
Até onde eu sei a postura do Bruno no J2EE Spider é, com já oi dito aqui, fazer o trabalho repetitivo. Isso significa que se você gerava uma classe e um arquivo em XML em duas horas na mão ele vai gerar a mesma coisa em 15 minutos. No fim das contas da manutenção dá no mesmo (se a ferramenta tiver qualidade, claro). Eu nunca usei o J2EE Spider mas já usei muitas ferramentas para este tipo de coisa.
O problema das coisas como o maker é que eles se propoem a substituir tudo, não só o trabalho repetitivo.
Eu não tinha visto a discussão, mas é exatamente isso.
O código criado pelo J2EE Spider é seu, não da ferramenta. O desenvolvedor tem liberdade para fazer qualquer manutenção quando necessário.
Inclusive sobre a discussão dos bugs, quem quiser pode consertar bugs nos artefatos gerados sem ficar dependente da ferramenta (só não esqueça de contribuir depois  ).
Então resumindo: se chegarem bugs em produção, praticamente posso dizer que a culpa é mais do desenvolvedor que não fez nenhum tipo de teste no seu projeto (teste unitário, teste funcional, etc...) do que da ferramenta. Lembrem-se o código é seu e pode ser criado exatemente do seu jeito se customizar o template.
A parte ruim do wavemaker (pelo que eu vi em um vídeo) são esses pontos:
não é integrado com nenhuma IDE de desenvolvimento (tudo é feito via browser);
ele é quase uma IDE dentro do browser, você tem que sair arrastando as coisas, com não é maduro com o Eclipse / Netbeans não sei se funciona... isso tem que ser levado em consideração... um erro bobo de javascript no core da IDE pode atrapalhar muita coisa;
você tem mais trabalho para montar um projeto do que usando o conceito de templates, porque no wavemaker é necessário criar tudo no drag and drop, ele é quase mais uma IDE do que uma "maker" então parece mais concorrente do Eclipse do que do SPIDER ou ferramenta de geração de código;
não mostrou como fica o código gerado... você é obrigado a manter tudo pelo Wavemaker e ficar escravo dessa ferramenta? E se ela gerar código errado como você vai concertar? E se tiver acesso ao código gerado (parece que não), é possível abrir ele onde? Eclipse? NetBeans?
o wavemaker se propõe a criar uma aplicação com Spring, Hibernate, JAXWS, ACEGI, Dojo e ponto. Você não consegue escolher se quer usar JSF ou Spring MVC ou mesmo struts (não é possível escolher os frameworks). Ou seja você que tem que se adaptar ao wavemaker e não o contrário.
etc, etc...
Fiz só algumas observações sobre o conceito do wavemaker, que não parece muito diferente daquele outro maker da Bahia. Tirando as diferenças visuais e um ou outro detalhe os dois seguem para o mesmo lado.
|
|
|
|
sene wrote:
bruno.braga wrote:
sene wrote:Mais de 500 TFLOPS 
250 vezes de muita coisa é muita coisa.
Sim mas, você viu a quantidade de processadores que esse supercomputador têm?
É, olhando por esse lado é realmente estranho hehe...
|
|
|
|
sene wrote:Mais de 500 TFLOPS
Daria pra rodar um jogo bem legal aí 
A propósito, os 2 TFLOPS do PS3 vem da mesma medida desses 500 aí de cima? Se sim, o PS3 é bem "violento". Ou ele não atinge os 2 TFLOPS que dizem por aí?
250 vezes de muita coisa é muita coisa.
|
|
|
|
|
parabéns por avançar com o projeto Michael... =)
|
|
|
|
Eu acho que o povo brasileiro tem muito potencial. Tudo que leva a serio e quer realmente fazer fica muito bom e até melhor do que se fosse feito por gringos...
Com certeza todo mundo já viu um exemplo disso e alguns já foram falados nesse tópico.
Mas ao mesmo tempo acho que o brasileiro não tem cultura de vestir a camisa e ajudar ou criar um projeto open source.
Já aconteceu várias vezes deu conversar com alguém sobre desenvolvimento de software e a pessoa me achar louco porque eu faço um projeto open source e não ganho dinheiro $$ com isso.
Acho que isso tem a ver com cultura..., q aos poucos tem que mudar e espero que esteja mudando.
Uma outra coisa que pesa muito na vontade do povo em ajudar é a divulgação, marketing, documentação e o boca a boca (ver outra pessoa usando ou falando do projeto motiva outras).
Falo isso porque até hoje eu estava / estou insatisfeito com a visão que eu passo desse projeto: J2EE Spider. Por isso eu mudei o site todo:
http://www.j2eespider.org
Esse novo site vai ser mais divulgado na próxima versão do projeto..., agora eu consegui explicar melhor algumas coisas, porque o site antigo não dizia nada
Então acho que isso interfere muito também... Saber passar o que é o projeto... E eu ainda não consegui transmitir o que eu queria... Mas como eu estou fazendo sozinho, aos poucos vou ajeitando...
p.s: sobre o 'louco'..., para as pessoas que eu sento pessoalmente e mostro a ferramenta funcionando, ai que me chamam de mais louco ainda, porque acham fantástico e que eu deveria cobrar por aquilo em vez de deixar usar de graça...
|
|
|
|
Em uma discussão sobre Geração de Código em outro tópico (de outra ferramenta) eu postei um texto que se encaixa bem a esse tópico.
Esse texto foi retirado de um artigo que escrevi para revista Mundo Java de maio de 2007 - número 23:
Geração de Código
Um gerador de código é uma ferramenta capaz de gerar artefatos através de diagramas, dados ou comandos.
Um fato curioso é que alguns desenvolvedores Java são um pouco resistentes ao termo "Geração de Código". Dada à diversidade de ferramentas dessa área, não podemos tirar toda a razão dessas pessoas. Muitos de nós talvez tenham se deparado com projetos que prometiam criar um sistema por completo usando geração de código, porém entendemos que isso não é a realidade do dia a dia. Não podemos substituir as pessoas, os programadores, criar regras de negócios automaticamente, prever e implementar soluções para todos os cenários somente gerando código. O computador não possui autonomia para sozinho atender aos nossos clientes exigentes =)... Muito menos foi projetado para tomar decisões no lugar das pessoas.
Então, para que serve geração de código? É algo ruim como alguns desenvolvedores imaginam? Vai gerar código que não preciso e atrapalhar o meu projeto?
A resposta é não! Geração de código não é ruim, não vai atrapalhar o seu projeto e nem tem o objetivo de criar código totalmente pronto.
Lógico que conhecemos algumas ferramentas que prometem mágica, mas essas falsas promessas são das ferramentas e não do conceito de geração de código.
Por falar nisso, vamos explorar um pouco desse conceito:
Se pararmos para pensar, todo projeto tem geração de código. Quer o desenvolvedor goste ou não.
Exemplos:
- Um wizard da IDE para criar novos projetos é um gerador de código. A partir de dados informados pelo usuário, a ferramenta vai gerar artefatos (arquivos).
- Por mais estranho que possa parecer, a compilação de código Java em arquivos class é geração de código. A partir de comandos de uma linguagem (Java) são gerados artefatos de outra linguagem (um ou mais arquivos class para cada arquivo java).
Esses exemplos para alguns pontos de vista podem parecer polêmicos. A verdade é que não existe uma definição única e fechada sobre geração de código. Vejamos por exemplo o que diz a Wikipedia:
"Gerador de Código é aquela ferramenta que possui a capacidade de gerar código a partir de um determinado modelo de software. Inclusive, de acordo com alguns pontos de vista e a partir das características específicas do tipo de Gerador de Código, ele passa a ser conversor de códigos de linguagens distintas. Isso acontece, por exemplo, com o compilador, que transforma um código escrito através de uma linguagem de programação para código de máquina ou código objeto."
Já Kathleen Dollard em 2004 no livro Code Generation in Microsoft .NET, foi mais genérica ainda ao definir: ?Geração de código é o código que gera código?. Em 2003, Jack Herrington no livro Code Generation in Action preferiu dividir a geração de código entre passiva e ativa. Onde os wizards seriam um exemplo de geração passiva, pois não mantém responsabilidade com o código gerado ? qualquer alteração depois da geração é realizada pelo desenvolvedor manualmente, e o tipo ativo que segundo ele mantém a responsabilidade - um código poderia ser gerado em ciclos e quando precisasse de alterações o desenvolvedor recorreria novamente a ferramenta de geração, forneceria novos dados e seria gerado o código de novo.
Preferimos não dividir a geração de código em tipos, até porque seguindo ao pé da letra as definições de Herrington, nosso projeto não tem geração de código 100% ativa nem passiva, ele é orientado as necessidades do desenvolvedor, podendo se comportar das duas formas no mesmo projeto inclusive. O que temos que ter em mente é que se havia alguma dúvida, agora é fato: a Geração de Código faz parte do dia a dia dos desenvolvedores e todos a utilizam, mesmo sem perceber. Ela é extremamente importante para evitar tarefas repetitivas ou trabalhosas, já que muitas podem ser automatizadas de alguma forma para ganhar produtividade. Só devemos lembrar que em nenhum momento a geração de código tem como objetivo fazer tudo sozinha.
Nos próximos tópicos, vamos avaliar como é a geração de código implementada pelo SPIDER e porque ela é interessante, sendo inclusive mais flexível do que muitas ferramentas que temos visto atualmente.
Para ler o artigo completo, compre a revista (não posso postar aqui, é claro....)
|
|
|
|
Eu venho mantendo um projeto open source que é uma ferramenta de GERAÇÃO DE CÓDIGO (não tenho vergonha em dizer isso).
Então pode dizer que eu tenho uma mente aberta para esse tipo de coisa. E mesmo assim não gostei desse Maker.
Vai contra tudo que eu penso que é certo. Uma ferramenta não pode substituir as pessoas dessa forma.
Eu penso que ferramentas de desenvolvimento só servem para ajudar as pessoas em algumas coisas. Mas mesmo assim são as pessoas que devem escolher ONDE querem ser ajudadas.
Se alguém quer ajuda para criar só um projeto em branco e codificar o resto, blz ela vai no wizard da IDE e cria só o projeto em branco. Se ela quer ajuda para mapear o banco, beleza ela vai em um Hibernate Tools da vida e mapeia o banco..., ou realiza o mapeamento na mão. Mas são as pessoas que escolhem onde querem ajudas para desenvolver um software. Isso de você ficar preso, sem escolhas e o software vir todo pronto e com certeza sem flexibilidade para você customizar/gerar de novo e não atrapalhar seu projeto eu não gosto muito... não faz sentido...
Mas aproveitando o tópico vou explicar o que eu penso sobre GERAÇÃO DE CÓDIGO (retirado de um artigo que escrevi para revista Mundo Java de maio de 2007 - número 23) e se encaixa perfeitamente neste tópico:
Geração de Código
Um gerador de código é uma ferramenta capaz de gerar artefatos através de diagramas, dados ou comandos.
Um fato curioso é que alguns desenvolvedores Java são um pouco resistentes ao termo "Geração de Código". Dada à diversidade de ferramentas dessa área, não podemos tirar toda a razão dessas pessoas. Muitos de nós talvez tenham se deparado com projetos que prometiam criar um sistema por completo usando geração de código, porém entendemos que isso não é a realidade do dia a dia. Não podemos substituir as pessoas, os programadores, criar regras de negócios automaticamente, prever e implementar soluções para todos os cenários somente gerando código. O computador não possui autonomia para sozinho atender aos nossos clientes exigentes =)... Muito menos foi projetado para tomar decisões no lugar das pessoas.
Então, para que serve geração de código? É algo ruim como alguns desenvolvedores imaginam? Vai gerar código que não preciso e atrapalhar o meu projeto?
A resposta é não! Geração de código não é ruim, não vai atrapalhar o seu projeto e nem tem o objetivo de criar código totalmente pronto.
Lógico que conhecemos algumas ferramentas que prometem mágica, mas essas falsas promessas são das ferramentas e não do conceito de geração de código.
Por falar nisso, vamos explorar um pouco desse conceito:
Se pararmos para pensar, todo projeto tem geração de código. Quer o desenvolvedor goste ou não.
Exemplos:
? Um wizard da IDE para criar novos projetos é um gerador de código. A partir de dados informados pelo usuário, a ferramenta vai gerar artefatos (arquivos).
? Por mais estranho que possa parecer, a compilação de código Java em arquivos class é geração de código. A partir de comandos de uma linguagem (Java) são gerados artefatos de outra linguagem (um ou mais arquivos class para cada arquivo java).
Esses exemplos para alguns pontos de vista podem parecer polêmicos. A verdade é que não existe uma definição única e fechada sobre geração de código. Vejamos por exemplo o que diz a Wikipedia:
"Gerador de Código é aquela ferramenta que possui a capacidade de gerar código a partir de um determinado modelo de software. Inclusive, de acordo com alguns pontos de vista e a partir das características específicas do tipo de Gerador de Código, ele passa a ser conversor de códigos de linguagens distintas. Isso acontece, por exemplo, com o compilador, que transforma um código escrito através de uma linguagem de programação para código de máquina ou código objeto."
Já Kathleen Dollard em 2004 no livro Code Generation in Microsoft .NET, foi mais genérica ainda ao definir: ?Geração de código é o código que gera código?. Em 2003, Jack Herrington no livro Code Generation in Action preferiu dividir a geração de código entre passiva e ativa. Onde os wizards seriam um exemplo de geração passiva, pois não mantém responsabilidade com o código gerado ? qualquer alteração depois da geração é realizada pelo desenvolvedor manualmente, e o tipo ativo que segundo ele mantém a responsabilidade - um código poderia ser gerado em ciclos e quando precisasse de alterações o desenvolvedor recorreria novamente a ferramenta de geração, forneceria novos dados e seria gerado o código de novo.
Preferimos não dividir a geração de código em tipos, até porque seguindo ao pé da letra as definições de Herrington, nosso projeto não tem geração de código 100% ativa nem passiva, ele é orientado as necessidades do desenvolvedor, podendo se comportar das duas formas no mesmo projeto inclusive. O que temos que ter em mente é que se havia alguma dúvida, agora é fato: a Geração de Código faz parte do dia a dia dos desenvolvedores e todos a utilizam, mesmo sem perceber. Ela é extremamente importante para evitar tarefas repetitivas ou trabalhosas, já que muitas podem ser automatizadas de alguma forma para ganhar produtividade. Só devemos lembrar que em nenhum momento a geração de código tem como objetivo fazer tudo sozinha.
Nos próximos tópicos, vamos avaliar como é a geração de código implementada pelo SPIDER e porque ela é interessante, sendo inclusive mais flexível do que muitas ferramentas que temos visto atualmente.
Então aproveitando o assunto deem uma olhada nesse notícia de hoje:
http://www.guj.com.br/posts/list/80877.java
Vídeos de demonstração
- versão windows (auto-executável)
http://downloads.sourceforge.net/j2eespider/spider...o-1.0.0-M1.exe?use_mirror=osdn
- versão multiplataforma (visualizado no browser)
http://downloads.sourceforge.net/j2eespider/spider...o-1.0.0-M1.zip?use_mirror=osdn
|
|
|
|
Pessoal, depois de um tempo de desenvolvimento interno, tenho o prazer de anunciar o "salto" da versão 0.3.0 para 1.0.0-M1 do SPIDER.
Mundaça de versão
A decisão dessa alteração se deu porque neste começo de projeto, em vez de liberar sub-versões com poucas alterações, eu resolvi ficar um tempo desenvolvendo um conjunto de features que achava necessárias e prioritárias antes de liberar para vocês. Isso inclui o suporte a geração de CRUD, que é um dos principais recursos do produto e ainda não havia sido implementado.
VÍDEO
Como de costume estou disponibilizando um vídeo demonstrativo para avaliarem alguns detalhes da ferramenta. Espero que gostem e não deixem de avaliar outros pontos que não puderam ser mostrados no vídeo (para não ficar mais extenso do que já estava):
- versão windows (auto-executável)
http://downloads.sourceforge.net/j2eespider/spider_video-1.0.0-M1.exe?use_mirror=osdn
- versão multiplataforma (visualizado no browser)
http://downloads.sourceforge.net/j2eespider/spider_video-1.0.0-M1.zip?use_mirror=osdn
Sobre o projeto
Para quem não conhece o projeto, é um bom momento para assistir e analisar o que está perto de ser a versão 1.0.0, e ver qual a abordagem utilizada no projeto para ganhar produtividade no dia a dia do desenvolvimento de projetos JEE.
Apesar da ferramenta estar ficando bastante interessante, ou em outras palavras - fácil de criar projetos com alguns clicks, devemos lembrar mais uma vez que o objetivo não é substituir as pessoas e sair criando projetos utilizando somente o SPIDER. O objetivo é eliminar as tarefas repetitivas que temos no dia a dia, como configuração de projetos, erros na integração de frameworks ou tirar das costas do desenvolvedor a responsabilidade de codificar artefatos que não possuem regras de negocio e uma ferramenta poderia criar em determinados contextos. As pessoas (nós desenvolvedores) podemos ser mais produtivos se estivermos mais focados nas decisões tecnológicas e regras de negocio da aplicação (só para citar alguns) e menos focado em infra-estrutura do projeto.
A idéia é ir mais direto ao ponto sobre as necessidades do cliente ou dos projetos usando uma IDE fácil, intuitiva, com muitos recursos e customizável.
Qualquer critica ou sugestão é bem vinda.
Segue em anexo o changelog com as principais alterações.
Problemas conhecidos:
- No grid do CRUD tem uma opção de campo obrigatório (um checkbox), mas ele não está funcionando porque eu não implementei nenhum código para ele ainda. Mas esse recurso pode ser usado usando o popup de validação.
Issue Tracker
Demais bugs podem ser cadastrados em:
http://jira.j2eespider.org
Vou viajar na sexta agora e volto só na semana seguinte ao carnaval. Enquanto isso avaliem e tentarei acessar a net de uma lan-house de vez enquanto e passar por aqui. Quando voltar estarei postando notícias e começando a divulgar essa release fora do Brasil também.
Deu trabalho, mas tá ai... =)
Abraços,
|
|
|
|
|
|