Migração para o VRaptor 3 Final

Assuntos Gerais
#1

Boa tarde,

Estou utilizando o VRaptor 3.0 desde o Beta 5. Uma dúvida que surgiu foi para migrar o projeto para a versão final. Algumas dúvidas:

  • Posso simplesmente substituir o JAR do VRaptor pelo da versão final?
  • O VRaptor 2.6 é uma dependência obrigatória?
  • Alguns JARs, como o do Hibernate Core, são versões mais antigas que as versões correntes (GA). Nesse caso, posso utilizar pela versão mais recente?
  • Seria possível em releases futuros separar a parte de libs por funcionalidades (ex.: file-upload, compatibilidade-v.2, validacao-hamcrest, etc). Uma divisão entre obrigatórios e opcionais já ajudaria muito.
  • Observei que nessa versão foram incluídos os JARs do spring e do pico-container. Isso não cria a possibilidade para algum tipo de conflito?

T+

#2

Duron, antes de mais nada não sou desenvolvedor do vraptor. Te passo apenas experiências que tive migrando um projeto meu.

Vraptor 2.6 não é dependencia obrigatória. Creio ser apenas para compatibilidade. Na verdade eu não usei todos os jars que são distribuídos no pacote. Apenas nos necessários.

No caso do Hibernate, creio que você possa sim usar outras versões. Normalmente versões mais novas possuem compatibilidade. O máximo que pode haver são alguns métodos depreciated não existirem mais. Uma leitura do changelog dos projetos é indicada.

No meu caso minha aplicação usa um módulo EJB standalone. Por isso não usei Spring, optei pelo Pico (por ser mais lightweight, jar menor, menos dependencias). Também não usei Hibernate (na verdade o hibernate fica no módulo EJB via JPA) , e nem mesmo usei o jar do vraptor-2.6.

Uma coisa que eu não gostei é que o vraptor sobe por padrão alguns “resources inbox”, um deles é o file-upload. Assim você precisa ter esse jar mesmo que não faça upload algum. Outro jar é o commons-vfs.

No caso do hamcrest eu já usava no meu módulo EJB, então exportei ele nas libs do domínio do container (uso glassfish).

Aproveitando já deixo uma sugestão de poder optarmos por usar, assim como é no hibernate, cglib ou javassist. Como no meu caso eu já uso javassist tenho esse jar no módulo EJB. Sei que para isso é necessário escrever as implementações para ambas, mas enfim, apenas uma sugestão.

O jar reflections não faz (quase) a mesma coisa que o mirror? São necessárias ambas?

Abraços

#3

[quote=Duron Maniac]Boa tarde,

Não precisa do VRaptor 2.6, pode atualizar o Hibernate a vontade…
A gente vai colocar os jars opcionais separados… Uma boa dica é: os jars que estão no vraptor-blank-project são os obrigatórios…

[quote=Duron Maniac]

  • Observei que nessa versão foram incluídos os JARs do spring e do pico-container. Isso não cria a possibilidade para algum tipo de conflito?[/quote]
    Você pode usar ou o spring ou o pico… não precisa dos dois jars… Se você não configurar nada, o padrão é o Spring…

o file-upload não deveria ser dependência obrigatória mesmo… mas fica meio difícil de tirar por enquanto…
Já o commons-vfs é dependência do reflections, que o usa para poder escanear as classes que estão dentro de jars…

Anotado, vamos ver se é simples fazer a implementação pra javaassist e deixar um jeito fácil de mudar a implementação

embora pelo nome pareça a mesma coisa, não é… o reflections faz scanning de classpath: pra eu conseguir
achar no classpath todas as classes anotadas com @Component por exemplo…
já o mirror é uma DSL para a API de reflections do java… pra eu poder fazer coisas do tipo:

mirror.on(Cachorro.class).invoke().method("late").withoutArgs();

sem precisar ficar tratando milhares de exceptions e coisas do tipo…

[]'s

#4

Lucas, obrigado pela informação.

De qualquer forma, cabe lembrar que dos frameworks que eu conheço/uso o vraptor é o que possui menos dependencias. Na minha app (que é apenas web) são 9 jars com aproximadamente 1.9M. Se você usar struts2 você coloca quase 8M (isso no básico). JSF com myfaces nem se fala. Até o insano digester vai de presente.

Abraços

#5