Não, porque se você gerar um jar pelo netbeans ou eclipse você seleciona quais source-folders vão para o jar. Caso você use o ant você pode também indicar quais pacotes vão. Basta você excluir todos onde o source folder é de teste.
(Lucas, e) VRaptor forks,
E realmente não tem jeito de configurar (registrar) via [color=red]somente código-fonte[/color] estes: EntityManagerCreator, EntityManagerFactoryCreator e JPATransactionInterceptor; em vez de no web.xml
<context-param>
<param-name>br.com.caelum.vraptor.provider</param-name>
<param-value>br.com.caelum.vraptor.util.jpa.JPACustomProvider</param-value>
</context-param> :?:
[quote=derlon](Lucas, e) VRaptor forks,
E realmente não tem jeito de configurar (registrar) via [color=red]somente código-fonte[/color] estes: EntityManagerCreator, EntityManagerFactoryCreator e JPATransactionInterceptor; em vez de no web.xml
<context-param>
<param-name>br.com.caelum.vraptor.provider</param-name>
<param-value>br.com.caelum.vraptor.util.jpa.JPACustomProvider</param-value>
</context-param> :?: [/quote]
Essa semana eu estava pensando nisso, e até pensei em sugerir um componente que você indicar os componentes que você quer inicializar, sem precisar do web.xml.
public interface Configurator {
List<?> doConfigure();
}
public class EmptyConfigurator {
public List<?> doConfigure() {
return Collections.emptyList();
}
}
Então se o desenvolvedor quiser subir o componente MeuComponente e o EntityManagerFactory teria algo como
public class CustomConfigurator {
public List<?> doConfigure() {
[...]
list.add(MeuComponente .class);
list.add(EntityManagerFactory.class);
return list;
}
}
Eu não sei se não dá para você sobrescrever o BaseComponents… Isso o Lucas que conhece bem.
Então, por enquanto o único jeito é criando um CustomProvider que estende SpringProvider e registra esses componentes…
ou registrando o JPACustomProvider mesmo…
o problema em criar um componente que registra outros componentes é que eu teria que executá-lo logo após iniciar o Spring, e após iniciar o Spring eu não posso simplesmente registrar novos componentes… Isso até funciona, mas eu precisaria dar um refresh no spring que reinstanciaria todos os componentes…
pode ser que tenha algo no spring que possibilite isso, mas não conheço…
Olá pessoal que manja do VRaptor3, tudo bom? =D
Estou analisando qual algumas tecnologias para iniciar um novo projeto e VRaptor3 é um dos candidatos.
Entretanto, tenho uma dúvida que cheguei a pesquisar nos demais posts mas não achei a resposta…
Reparei que tanto no tutorial de 3 minutos, quanto no de 10 ou no mydvds, há annotations do vraptor em controllers, Daos e etc. Reparei também nos testes das Controllers (ou seja, há regra de negócio e/ou validações nas controllers) e na utilização das DAOs direto nas Controllers. Finalmente, uma última observação: no modelo, mydvd, não há separação de projetos, (como um projeto só para a regra de negócio, outro para a parte de visualização e etc).
Minha dúvida é sobre o alta dependência da tecnologia (no caso VRaptor) com a implementação do projeto. Não seria mais interessante se as camadas fossem mais isoladas, para serem mais portáteis?
Recentemente participei de um projeto onde a regra de negócio (entidades/serviços/repositorios/daos e etc) estava bem isolada em um jar com seus testes de unidade. No meio do projeto, devido a baixa produtividade que a equipe estava tendo no projeto da camada de visualização (JSF+Facelets+RichFaces), foi decidido alterar a tecnologia. Foi criado um novo projeto para camada de visualização utilizando Struts2+Tiles+JQuery, e referenciado o jar com a regra de negócio.
Como todas as camadas estavam isoladas, toda a regra de negócio estavam nos objetos, serviços, repositorios e etc e eram acessadas por fachadas a mudança foi muito simples, bastando efetuar as chamadas que eram feitas nos ManagedBeans nas Actions.
Lógico que houveram adaptações, porém o importante é que não foi necessário re-escrever nenhuma regra de negócio e que a transição foi muito rápida.
A melhor abordagem ao utilizar o VRaptor é realmente manter as regras/validações nas controllers (que, como há testes de unidade, entendo que são encaradas como parte do negócio), e utilizar as DAO’s nas controllers mesmo, e deixar tudo em um mesmo projeto, como o modelo MyDvds?
Qual seria um possível modelo ao utilizar uma abordagem mais DDD em um projeto VRaptor?
Por favor me perdoem pela mensagem verborragica, realmente as vezes me acho muito prolixo, porém não encontrei uma maneira mais sucinta de descrever a minha dúvida.
Se houver algum post que comente esses tópicos, por favor me indiquem.
Agradeço antecipadamente,
Então, rogério,
você pode sim ter um projeto pra cada área do seu sistema sem problemas…
a única coisa é que pra usar a parte de Injeção de Dependências do VRaptor vc precisa usar algumas das suas anotações… se vc não quiser isso, vc pode gerenciar as dependências diretamente num xml do spring, só é mais trabalhoso, mas deixaria seus daos/repositories desacoplados do vraptor…
de qqer forma, o acoplamento com o vraptor é só via anotações, que vc pode simplesmente apagar depois…
o VRaptor está com planos de usar anotações padrão do java pra fazer a injeção de dependências, daí eliminaria esse acoplamento tbm…
as views já são totalmente desacopladas do vraptor, e a parte dos Controllers vc consegue isolar do seu código de negócio…
Talvez o que eu fale aqui o Lucas já tenha dito, mas a minha opinião é mais de usuário que a dele :D. O Vraptor não é (tão) acoplado a nenhuma classe interna dele porque você não precisa estender nem implementar (quase) nada. As únicas classes que você precisa implementar amarradas diretamente ao vraptor são os converters e interceptors. Porém como esses componentes são de infra não vejo um problema. O fato de ter anotações não significa (forte) acoplamento, pois você pode facilmente remove-las sem muita perda de tempo. Ou seja, acoplamento muito baixo.
Você disse que usa JSF. Ele sim é bem intrusivo, pois você precisa trabalhar direto com os seus componentes (ex SelectItem). No Vraptor você pode trabalhar totalmente sem sequer saber quem é Vraptor, excetuando o uso do @Resource, que é a única coisa do Vraptor que você não tem como escapar de usar. Todas as outras são bem opcionais. Por exemplo, se você usa EJB não precisará de @Component para daos, repositórios e business.
O core do Vraptor é ser um controlador, sendo assim você pode usá-lo apenas como controlador unido a N tecnologias, seja suas proprias classes de negócio “made in home”, EJB, Spring ou as camadas do Vraptor. Os projetos de exemplo são meros exemplos, e você pode expandir esses exemplos conforme suas necessidades. Eu por exemplo uso o Vraptor atuamente em 8 projetos com EJB3 remoto, sendo que o Vraptor atua apenas no controlador, e a camada view é feita via JSPX. Eu vejo as daos como meros componentes opcionais do Vraptor, e você pode nem mesmo querer usar eles, como é meu caso.
Eu sou dos tempos que o Struts estava recém aparecendo no mercado, e nele você tinha dependencias direta do framework porque era necessário não apenas você estender as classes, mas também respeitar uma assinatura de método. No Vraptor você pode escrever seu método como bem entender e ele se vira para injetar os parametros, sejam lá qual for.
Hoje em dia dizer que você terá um sistema 100% desacoplado me parece um pouco utópico. O que você tem são sistemas que você pode ter poucas dependencias que facilitem a migração para uma nova tecnologia, porém nunca você poderá dizer que vai sair de um framework X para Y sem mexer em nada. Até mesmo no JPA você precisa alterar as propriedades dentro do persistence.xml antes de mudar seu provider. A grande vantagem no Vraptor é que essa dependencia é quase nula.
[quote=rogerio.alcantara]… No meio do projeto, devido a baixa produtividade que a equipe estava tendo no projeto da camada de visualização (JSF+Facelets+RichFaces), foi decidido alterar a tecnologia…[/quote]Nesse ponto, a opção + simples e óbvia 8) seria adotar SeamFramework!! (mas, aki isto já iria off-topic :shock: )
[quote=rogerio.alcantara]…A melhor abordagem ao utilizar o VRaptor é realmente manter as regras/validações nas controllers (que, como há testes de unidade, entendo que são encaradas como parte do negócio), e utilizar as DAO’s nas controllers mesmo, e deixar tudo em um mesmo projeto, como o modelo MyDvds?[/quote]Rogerio, neste aspecto concordo totalmente contigo!!:thumbup: Sou [color=red]totalmente contra[/color] codificar Validações na Camada (Web)FrontController, pois Lógica, Fluxo e Regras de Negócio devem ficar no Business-Core da Aplicação e, francamente, a maior parte (quando não todas) das Validações são Regras de Negócio.[quote=rogerio.alcantara]… Foi criado um novo projeto para camada de visualização utilizando Struts2+Tiles+JQuery, e referenciado o jar com a regra de negócio.
omo todas as camadas estavam isoladas, toda a regra de negócio estavam nos objetos, serviços, repositorios e etc e eram acessadas por fachadas a mudança foi muito simples, bastando efetuar as chamadas que eram feitas nos ManagedBeans nas Actions.
Qual seria um possível modelo ao utilizar uma abordagem mais DDD em um projeto VRaptor?
…[/quote]Oh Rogério, parece q vc tá lendo o meu pensamento. 
É, atualmente estou muito seduzido por essa abodágem de implementar a API do Business-Core em 1 Projeto .JAR(expondo as funcionalidades via interface: Façade de Serviço) e então adicioná-lo ao [b]Projeto .WAR/b
Mas, com certeza: podemos implementar, sim, :XD: DDD com o v|raptor3!! :thumbup: E isto é até muito facilitado devido a integração [color=blue]transparente[/color] do VRaptor com o Spring. Apenas, devemos mudar algumas abordágens como, por exemplo, a Persistência deve ser Gerenciada pelo Container (no caso, Spring) e tudo + de [color=red]Infra[/color] de forma transversal; enfim: tirar todo o proveito possível da [color=red]AOP[/color] (do Spring).
Espero ter sido claro! Se faltou alguma coisa, é só postar!! :lol: 1 ]o['ão,
:thumbup: :thumbup:
Já que não achei uma emoticon de reverência, usei essa, hehe.
Atualmente uso assim. Módulo EJB valida tudo, desde campos nullables quanto regra de negócio.
[quote=garcia-jj]…
Não, porque se você gerar um jar pelo netbeans ou eclipse você seleciona quais source-folders vão para o jar. …[/quote]
Garcia, E no Eclipse realmente não tem mesmo como fazer esta configuração de Incluir/Excluir SrcPacks/.JARs só q EM Projetos (Web) .WAR??! 
Derlon, se você ir no projeto, propriedades, Java Build Path, Order and Export você pode marcar quais vão para o export ou não.
Garcia,
Sua orientação procede rigorosamente. Porem, tanto o item Pack de Source (código-fonte da minha Ap. propriamente dito), como o de Testes (testes.src) aparecem desabilidos com “um quadradinho” em seus CheckBoxes, ou seja, não consigo checkar e/ou descheckar o CheckBox desses itens. :shock:
Vc saberia dizer pq acontece isto??! :?:
se vc usar o maven ou o ant pra gerar seus wars vc não vai ter esse problema
Muito obrigado ao @LucasCavalcanti, @garcia-jj e ao @derlon pelos esclarecimentos e aos demais pela atenção.
Sim, acho que farei um projeto a parte para o core/testes do negócio (JAR) e um projeto web (WAR), pois da última vez ficou muito legal! 
Se for o caso de optar pelo VRaptor3, provavelmente precisarei de ajuda na configuração dos projetos e tenho certeza que poderei contar com vcs!
Mais uma vez, muito obrigado pela atenção!
[quote=derlon]Garcia,
Sua orientação procede rigorosamente. Porem, tanto o item Pack de Source (código-fonte da minha Ap. propriamente dito), como o de Testes (testes.src) aparecem desabilidos com “um quadradinho” em seus CheckBoxes, ou seja, não consigo checkar e/ou descheckar o CheckBox desses itens. :shock:
Vc saberia dizer pq acontece isto??! :?: [/quote]
Bah, o pior que você tem razão, não dá para desabilitar. Agora que eu olhei isso e é verdade.
Complementando ao comentário do Lucas, por um lado a IDE mesmo tendo a facilitade de gerar um war, a funcionalidade principal é ser um ambiente de desenvolvimento. Para gerar seu WAR/EAR o ideal mesmo é usar um Ant ou Maven (eu uso o Ant). No meu caso eu trabalho sempre com a IDE para desenvolver, e quando vou empacotar a aplicação para enviar ao cliente o Ant gera um pacote com EAR e até os scripts do banco para migrar as versões, além de ofuscar os códigos, já que 70% das minhas aplicações são vendidas a N clientes.
Como eu te disse antes, eu separo dentro do Eclipse os source-folders em /src e /test, obviamente src para os fontes do projeto e test para as classes envolvidas no teste. Quando eu quero rodar todos os testes posso usar a IDE ou rodar uma Ant Task que faz isso tudo para mim.
Além disso a cada commit no repositório do SVN há uma outra task que roda os planos de teste e faz o deploy da aplicação em um ambiente de desenvolvimento central. Há um post no blog da caelum sobre integração continua: http://blog.caelum.com.br/2008/11/04/integracao-continua/