Oi pessoal
Depois de atingir 8 mil downloads, mais uma nova versão do VRaptor. Changelog em:
http://vraptor.caelum.com.br/documentacao/changelog/
Parabéns ao Lucas Cavalcanti, Caio Filipini, Tomaz Lavieri e Otávio Garcia pelos commits, patches e release.
Agora é rumo ao 3.2 e uma maior integração com o Java EE 6.
Opa, excelente notícia.
Já atualizei o JAR nas minhas libs.
Mas também achei interessante essa frase sobre a versão 3.2.
Já foi publicado algum conteúdo sobre a versão 3.2?
Parabéns pelo excelente trabalho.
[]´s
Daniel
[quote=Paulo Silveira]
Agora é rumo ao 3.2 e uma maior integração com o Java EE 6.[/quote]
Maravilha… atualizando++;
Mas que notícia boa. Há alguns dias já tenho usado a versão snapshot e as impressões eram as melhores. E os 8 mil downloads mostram que o framework tem conquistado cada dia mais desenvolvedores e projetos país afora (e quem sabe mundo afora, já que esses tempos respondí a dúvidas de gringos aqui no fórum).
Tenho um gosto muito grande pelo Vraptor por estar sempre a frente integrando o que há de melhor.
Fico feliz em poder contribuir de uma forma ou outra, já que uso o Vraptor em uma série de projetos. E espero sempre poder contribuir, seja com código, com testes, ou enchendo o saco, hahahahaha.
Isso é uma notícia muito boa, e pergunto: será que em um futuro próximo podemos ter o próprio container como provider, assim como está no JSF?
container como provider?
CDI ao invés do Spring. Hoje no JSF você injeta seus componentes através do CDI, então pensei se o Vraptor pode futuramente usar o CDI ao invés do Spring.
Maravilha!!
Para fazer um upgrade na aplicação, pode pegar os jars dessa nova versão e jogar na /lib do projeto substiruindo os já existentes?
Abraço!!!
o CDI não substitui o Spring 
ele só torna o processo de injeção de dependências genérico, através da spec… da mesma forma que a JPA não substitui o Hibernate…
de qqer forma, não sei se o Spring já está de acordo com o CDI… mas a gente tem planos sim de suportar, ou implementar, o CDI…
suportar quer dizer habilitar os componentes do CDI para serem usados nos do vraptor, que nem acontece agora com o Spring
implementar quer dizer seguir a spec, ou seja, o vraptor seria uma implementação CDI válida… não sei qual é a viabilidade disso…
[quote=Guevara]Maravilha!!
Para fazer um upgrade na aplicação, pode pegar os jars dessa nova versão e jogar na /lib do projeto substiruindo os já existentes?
Abraço!!![/quote]
sim, basicamente é isso…
você pode só substituir o vraptor-3.1.1.jar pelo vraptor-3.1.2.jar, teoricamente…
YES!!!
bom ver a 3.1.2 live!! \o/ … sempre bom ajudar…
desde o inicio eu só enchia o saco do Lucas uhuhuh, pedindo e pedindo coisas, mas nessa versão deu pra colaborar de verdade!!
…
Duvida? => Espaço ppara plug-in no site vai vim ?
[quote=Lucas Cavalcanti]o CDI não substitui o Spring
ele só torna o processo de injeção de dependências genérico, através da spec… da mesma forma que a JPA não substitui o Hibernate…
de qqer forma, não sei se o Spring já está de acordo com o CDI… mas a gente tem planos sim de suportar, ou implementar, o CDI…
suportar quer dizer habilitar os componentes do CDI para serem usados nos do vraptor, que nem acontece agora com o Spring
implementar quer dizer seguir a spec, ou seja, o vraptor seria uma implementação CDI válida… não sei qual é a viabilidade disso…[/quote]
Dentro do container Java EE ira substituir se o container não implementar o CDI com o Spring…
Segundo relatos do garcia, o spring verifica o @Inject e tenta fazer o gerenciamento, inclusive isso deu problema, pois ele estava rodando o Spring o Vraptor tudo dentro de um container Java EE, dando conflitos com o CDI do container…
ESTOU NA LUTA! para torar o vraptor compativel com o CDI do java ee ^^ …
muito bom versão nova…! to baixando agora…
sim, vamos fazer isso…
só precisa definir um pouco melhor o que é um plugin, fazer uma documentaçãozinha de como “instalar” esse plugin, e achar um lugar no site pra colocá-lo…
por enquanto a gente tá linkando para os plugins/posts que o pessoal anda fazendo nessa página:
Eu ainda não lí toda a spec JEE6 da parte web me interessei pouco, sou mais dos EJBs e infra. Mas pelo pouco que já lí você pode sim ter CDI direto to container e sem Spring. Um exemplo é que o JSF injeta isso via container, sem precisar das magias do Spring. Vou ver se essa semana dou uma lida melhor nessa parte da spec para não falar besteira.
Fiz uns testes com um projeto que está em faces e deu tudo certo, injetando objetos via CDI. Quando coloco o Vraptor aí o Spring entra em ação e atrapalha tudo.
Oi pessoal!
Gostaria de saber quando vão integrar o Restrictrex do Bronx ao Vraptor, acho que o plugin que ele inventou é bom demais para ser deixado de fora, facilita e muito o controle de login. Se nao puderem integrar, pelo menos poderiam colocar na seção de plugins (a futura seção de plugins) do Vraptor o link para download e tutorial dele disponíveis para todos.
Meu voto é que seja integrado, o usuário pode ou não usar, se o cara quiser usar outra coisa, que remova o Restrictrex e use o que achar melhor, mas pelo menos quem está chegando agora (eu por exemplo), terá uma ferramenta de controle de login disponível e de fácil manuseio no VRaptor.
O que acham?
Abraço!
se eu não me engano o bronx não deixou o código do restrictrex aberto, então não dá pra integrar ao vraptor…
e o link pra ele já está na página do vraptor:
http://vraptor.caelum.com.br/comunidade.jsp
desde que fiquei sabendo da versao 3 do VRaptor me entusiamei bastante, cheguei a ir numa palesta em um sabado de manhã, só tenho elogios para fazer ao projeto e a equipe, sempre disposta em atendar as duvidas e tb a comunidade que se amplia…
tenho usado o vraptor num grande projeto que esta em pleno dsenvolvimento, com bastante produtivade, como vai ser um projeto de um sistema on line aberto ao publico, quando estiver total em produção disponibilizarei como um case de sucesso utilizando o vraptor!!!
Parabens galera!
Ate mais
Cheguei a fazer isso também.
Perder o futebol no sábado de manhã… Só se valer muito a pena!
Confesso que ainda não sai da versão 3.0.2. Até pq fiz uma versão “custom” aqui na parte de validações: no “meu” vraptor eu posso gerar objetos distintos (“ValidationError”) para cada erro de validação. Acho que o Lavieri chegou a fazer algo do tipo, mas já tinha feito a minha, então não precisei mudar para a dele, que é [bem] menos intrusiva, porém levemente mais “complexa”. Por conta disso eu teria que replicar isso para cada nova versão que saísse, para manter a compatibilidade.
Mentira! Blasfêmia!
Cara, acho que até falei lá que por mim, quem quisesse copiar o código e falar pro chefe que foi ele que fez, por mim tava perfeito…hehehe
Sério, se achar que vale a pena deixar aquilo “nativo”, usem e abusem do código! Só peço créditos para mostrar pra minha mãe… Ela ainda acha que eu só fico vendo pornografia enquanto estou na frente do PC…^^
Mas é isso ae! VRaptor FTW!
ops, confundi, sorry 
teve uma pessoa que fez um controle de login, e não queria abrir o código com medo de copiarem e ganharem dinheiro com ele…
enfim, se a gente incluir isso no vraptor, vai ficar com créditos, com certeza
se vc quiser, você pode até abrir um fork do vraptor no github, commitar lá, daí a gente faz o merge e o commit fica com o seu nome
[quote=Guevara]Meu voto é que seja integrado, o usuário pode ou não usar, se o cara quiser usar outra coisa, que remova o Restrictrex e use o que achar melhor, mas pelo menos quem está chegando agora (eu por exemplo), terá uma ferramenta de controle de login disponível e de fácil manuseio no VRaptor.
O que acham?[/quote]
Já que foi perguntando, vou meter um pouco o bedelho. Eu sou contra, e até já citei isso em uma outra issue no github.
O core do vraptor é ser um controlador, e isso ele faz muito bem. Adicionar converters, features de validações e afins fica dentro do core. Porém adicionar uma funcionalidade muito especifica e adicional como login não me soa muito bem.
Penso que seria mais aconselhável vir como o projeto para scala, vir separado, e se alguém quiser basta colocar o JAR. É como você comprar um carro e vir com item de série aquelas correntes para andar na neve. Se você quiser andar em rodovias normais você precisa remover o item.
Enfim, IMHO.
@Lucas, não era sistema de login! … era um sistema de CRUDs, um cara fez uma parada WEB que criava todos os CRUDs com vraptor, REMOVE/INSERT/DELETE/UPDATE e tava com medo de abrir código
@Garcia-jj não quero desvirtuar o topico de forma alguma, mas concordo 100% com o cê, e analogia das correntes é perfeita =P … o controle de lógin é para ser um plug-in, adicionou o .jar funcionou, e quem não precisar não adiciona…
Beleza, se for para adicionar um jar e tiver instruções de uso já está muito bom. =)
Só acho que essas instruções poderiam estar mais claras e visíveis, para que o usuário pudesse adicionar o plugin do Bronx ou qualquer outro, eu por exemplo tive que dar várias voltas pelo tópico pra poder entender o funcionamento do plugin. Seria interessante o criador elaborar um tutorial para que seja postado no site da Caelum na seção de plugins, ou quem sabe numa wiki. Isso vale para os outros plugins, pelo que eu vi lá no site alguns são apenas um link para um tópico do GUJ, ai o usuário precisa garimpar cada postagem para entender.
Não seria interessante criar uma wiki com tutoriais e links para download direto do plugin? =)
Abraço!