VRaptor 4 + CDI 2.0

[Rodrigo Turini]

oi, pessoal

só uma pesquisa rápida: alguém está usando vr 4 com cdi 2.0 e weld 3+ em produção? Vou atualizar um projeto, e ao mesmo tempo fazer as mudanças que forem necessárias no core do vraptor e plugins. 

Compartilhem se tiverem passado por alguma experiência migrando (;

abracos

[Edi Linux]

É possível usar CDI 2.0 no VRaptor 4?

Eu tentei e não consegui, não consegui subir o projeto com o Weld 3...

[Rodrigo Turini]

oi Edi

é possível sim! atualizei os meus projetos sem grandes problemas. Em resumo, mudei a versao do weld p/ 3.0.x, adicionei o cdi-api 2.0 no pom:

<dependency>

    <groupId>javax.enterprise</groupId>

    <artifactId>cdi-api</artifactId>

    <version>2.0</version>

</dependency>

dei exclude no cdi-api 1.0 que vinha no vraptor e alguns plugin, e também dei exclude dos modulos weld-jsf e weld-probe-core que certamente nao seriam necessários. 

<dependency>

  <groupId>org.jboss.weld.servlet</groupId>

  <artifactId>weld-servlet-core</artifactId>

  <version>3.0.2.Final</version>

<exclusions>

  <exclusion>

     <artifactId>weld-jsf</artifactId>

     <groupId>org.jboss.weld.module</groupId>

   </exclusion>

   <exclusion>

     <artifactId>weld-probe-core</artifactId>

     <groupId>org.jboss.weld.probe</groupId>

   </exclusion>

   <exclusion>

     <artifactId>cdi-api</artifactId>

     <groupId>javax.enterprise</groupId>

   </exclusion>

</exclusions>

</dependency>

alguns detalhes pequenos mudam de uma versão da spec para outra, então dependendo e quais recursos você usar, vai precisar ajustar mais alguma coisa. Se esbarrar em algum problema nos mande por aqui na lista, que vamos ajudando. 

abracos

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

[Valério]

Pessoal,

Fui rodar o VRaptor 4.2.2 no WildFly 17 (Java EE 8 e CDI 2.0) e estou tomando o erro abaixo:

Meu pom.xml tá assim:

<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>

    <dependency>
  <groupId>br.com.caelum</groupId>
  <artifactId>vraptor</artifactId>
  <version>4.2.2</version>
  </dependency>

16:25:50,275 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /scd/: br.com.caelum.vraptor.InterceptionException: br.com.caelum.vraptor.InterceptionException: javax.enterprise.inject.CreationException
        at br.com.caelum.vraptor.interceptor.StepInvoker.invokeMethod(StepInvoker.java:69)
        at br.com.caelum.vraptor.interceptor.StepInvoker.tryToInvoke(StepInvoker.java:55)
        at br.com.caelum.vraptor.interceptor.StepInvoker$Proxy$_$$_WeldClientProxy.tryToInvoke(Unknown Source)
        at br.com.caelum.vraptor.interceptor.InterceptorExecutor.executeAround(InterceptorExecutor.java:75)
        at br.com.caelum.vraptor.interceptor.InterceptorExecutor$Proxy$_$$_WeldClientProxy.executeAround(Unknown Source)
        at br.com.caelum.vraptor.interceptor.AspectStyleInterceptorHandler.execute(AspectStyleInterceptorHandler.java:85)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:83)
        at br.com.caelum.vraptor.interceptor.ExceptionHandlerInterceptor.intercept(ExceptionHandlerInterceptor.java:75)
        at br.com.caelum.vraptor.interceptor.ExceptionHandlerInterceptor$Proxy$_$$_WeldClientProxy.intercept(Unknown Source)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler$1.call(ToInstantiateInterceptorHandler.java:71)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler$1.call(ToInstantiateInterceptorHandler.java:68)
        at br.com.caelum.vraptor.core.Try.run(Try.java:18)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.executeSafely(ToInstantiateInterceptorHandler.java:68)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.execute(ToInstantiateInterceptorHandler.java:61)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:83)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack.start(DefaultInterceptorStack.java:93)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack$Proxy$_$$_WeldClientProxy.start(Unknown Source)
        at br.com.caelum.vraptor.observer.RequestHandlerObserver.handle(RequestHandlerObserver.java:93)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
        at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
        at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
        at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
        at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
        at org.jboss.weld.util.Observers.notify(Observers.java:166)
        at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
        at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
        at org.jboss.weld.event.EventImpl.fire(EventImpl.java:96)
        at br.com.caelum.vraptor.VRaptor.doFilter(VRaptor.java:123)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
        at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$910/567208514.call(Unknown Source)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$911/1416333397.call(Unknown Source)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$911/1416333397.call(Unknown Source)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$911/1416333397.call(Unknown Source)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$911/1416333397.call(Unknown Source)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$911/1416333397.call(Unknown Source)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
        at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
        at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
        at java.lang.Thread.run(Thread.java:745)
Caused by: br.com.caelum.vraptor.InterceptionException: javax.enterprise.inject.CreationException
        at br.com.caelum.vraptor.interceptor.StepInvoker.invokeMethod(StepInvoker.java:69)
        at br.com.caelum.vraptor.interceptor.StepInvoker.tryToInvoke(StepInvoker.java:55)
        at br.com.caelum.vraptor.interceptor.StepInvoker$Proxy$_$$_WeldClientProxy.tryToInvoke(Unknown Source)
        at br.com.caelum.vraptor.interceptor.InterceptorExecutor.executeAround(InterceptorExecutor.java:75)
        at br.com.caelum.vraptor.interceptor.InterceptorExecutor$Proxy$_$$_WeldClientProxy.executeAround(Unknown Source)
        at br.com.caelum.vraptor.interceptor.AspectStyleInterceptorHandler.execute(AspectStyleInterceptorHandler.java:85)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:83)
        at br.com.caelum.vraptor.interceptor.FlashInterceptor.intercept(FlashInterceptor.java:98)
        at br.com.caelum.vraptor.interceptor.FlashInterceptor$Proxy$_$$_WeldClientProxy.intercept(Unknown Source)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler$1.call(ToInstantiateInterceptorHandler.java:71)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler$1.call(ToInstantiateInterceptorHandler.java:68)
        at br.com.caelum.vraptor.core.Try.run(Try.java:18)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.executeSafely(ToInstantiateInterceptorHandler.java:68)
        at br.com.caelum.vraptor.core.ToInstantiateInterceptorHandler.execute(ToInstantiateInterceptorHandler.java:61)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack.next(DefaultInterceptorStack.java:83)
        at br.com.caelum.vraptor.core.DefaultInterceptorStack$Proxy$_$$_WeldClientProxy.next(Unknown Source)
        at br.com.caelum.vraptor.interceptor.DefaultSimpleInterceptorStack.next(DefaultSimpleInterceptorStack.java:49)
        at br.com.caelum.vraptor.interceptor.DefaultSimpleInterceptorStack$Proxy$_$$_WeldClientProxy.next(Unknown Source)
        at web.scd.controller.interceptor.GeneralInterceptor.intercept(GeneralInterceptor.java:44)
        at web.scd.controller.interceptor.GeneralInterceptor$Proxy$_$$_WeldClientProxy.intercept(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at net.vidageek.mirror.provider.java.PureJavaMethodReflectionProvider.invoke(PureJavaMethodReflectionProvider.java:38)
        at net.vidageek.mirror.invoke.MethodHandlerByMethod.withArgs(MethodHandlerByMethod.java:54)
        at br.com.caelum.vraptor.core.DefaultReflectionProvider.invoke(DefaultReflectionProvider.java:42)
        at br.com.caelum.vraptor.core.DefaultReflectionProvider$Proxy$_$$_WeldClientProxy.invoke(Unknown Source)
        at br.com.caelum.vraptor.interceptor.StepInvoker.invokeMethod(StepInvoker.java:64)
        ... 86 more
Caused by: javax.enterprise.inject.CreationException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
        at java.lang.Class.newInstance(Class.java:433)
        at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40)
        at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:50)
        at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:90)
        at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:127)
        at org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:92)
        at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
        at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
        at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112)
        at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:186)
        at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:160)
        at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
        at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
        at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:177)
        at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
        at br.com.caelum.vraptor.view.DefaultLogicResult$Proxy$_$$_WeldClientProxy.forwardTo(Unknown Source)
        at br.com.caelum.vraptor.core.AbstractResult.forwardTo(AbstractResult.java:46)
        at br.com.caelum.vraptor.core.DefaultResult$Proxy$_$$_WeldClientProxy.forwardTo(Unknown Source)
        at web.scd.controller.interceptor.AuthorizationInterceptor.intercept(AuthorizationInterceptor.java:46)
        at web.scd.controller.interceptor.AuthorizationInterceptor$Proxy$_$$_WeldClientProxy.intercept(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at net.vidageek.mirror.provider.java.PureJavaMethodReflectionProvider.invoke(PureJavaMethodReflectionProvider.java:38)
        at net.vidageek.mirror.invoke.MethodHandlerByMethod.withArgs(MethodHandlerByMethod.java:54)
        at br.com.caelum.vraptor.core.DefaultReflectionProvider.invoke(DefaultReflectionProvider.java:42)
        at br.com.caelum.vraptor.core.DefaultReflectionProvider$Proxy$_$$_WeldClientProxy.invoke(Unknown Source)
        at br.com.caelum.vraptor.interceptor.StepInvoker.invokeMethod(StepInvoker.java:64)
        ... 114 more
Caused by: java.lang.NoSuchMethodError: org.jboss.weld.interceptor.util.proxy.TargetInstanceProxy.getTargetInstance()Ljava/lang/Object;
        at br.com.caelum.vraptor.proxy.CDIProxies.unproxifyIfPossible(CDIProxies.java:50)
        at br.com.caelum.vraptor.view.DefaultLogicResult.<init>(DefaultLogicResult.java:82)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
        at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:119)
        ... 140 more

Att,

Valério

[Valério]

Alguém conseguiu rodar apps com VRaptor 4.x em containeres com CDI 2.0?

Att,

Valério

[Renato Resende Ribeiro de Oliveira]

Você vai precisar adicionar a BOM do wildfly pra usar as versões corretas.

Coloque a dependência do cdi-api também. Verifique a árvore de dependências do seu POM pra ver se a versão que foi utilizada é a correta e verifique se não há duas versões do CDI e Weld no classpath do seu arquivo war.

PS: Eu nunca rodei em CDI 2, esses são os passos que eu seguiria pra tentar fazer rodar 

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CANtaK10XM6PaRifjSMFm9megKs%2B%3DhmtyaoikJMLi-5PoOckTqw%40mail.gmail.com.

--

Renato Resende Ribeiro de Oliveira
Senior Software Engineer @ Edvisor.io
MSc - Computer Science - Universidade Federal de Lavras

PMP - Project Management Professional

Skype: renatorro.comp.ufla.br

LinkedIn: https://www.linkedin.com/in/renatorro

[Valério]

Pessoal, estou retomando esse projeto agora. Alguem evoluiu nesse aspecto, de rodar o VRaptor 4.2.0 no CDI 2.0?

Vi que no GitHub tem um VRaptor 4.3 beta que parece rodar, mas o projeto está parado faz tempo. A Caelum tem interesse em manter o VRaptor? Se falou há um tempo atrás de uma nova versão que fosse alinhada à MVC Spec.. enfim, acho que toda a comunidade usuária do framework tem interesse em saber.

Abraço!

Att,

Valério

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNokda63fSj%3D2ftVgkmd6BJqhxHzHAVysDp62JmuTZUypcg%40mail.gmail.com.

[Valério]

@Rodrigo Turini

Desculpe a insistência, mas a Caelum tem interesse ou planos de manter o projeto VRaptor? Pelo menos pra rodar no Java EE 8/CDI 2.0?

Att,

Valério

[JSL Soluções]

I have fixed problems with wildfly 18.

Add:
<dependency> <groupId>com.jslsolucoes</groupId> <artifactId>vraptor</artifactId> <version>4.3.1</version> </dependency>

and excludes another versions if exists in your classpath (dependencies of plugins for example).

 

A quem for interessado. Abandonaram o projeto pelo visto. Corrigi os problemas e publiquei no meu repositorio a correção. É pra funcionar no wildfly18+ entre outros.

Referencia: https://github.com/caelum/vraptor4/issues/1142 

[Valério]

Deus te abençoe, meu amigo. =))

Att,

Valério

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/a8bf8f4e-8ff3-4890-9d2d-8905a90294f3%40googlegroups.com.

[Carlos Spohr]

Não sei a estratégia deles neste momento, principalmente agora com o cenário da covid, mas acho conveniente que eles definam alguém da comunidade para dar continuidade ao projeto, digo isso aos inúmeros issues abertos no github e também os pedidos de merge parados lá.

O Jonatan foi herói fazendo o fix para o Wildfly 18 e compartilhando com a galera, porém acho complicado usarmos repositórios de terceiros para atualizar os nossos projetos, não tirando o seu mérito por favor, apenas para relembrar a importância dos gestores do projeto elencarem quem possa dar continuidade ao vraptor.

Att. Carlos.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CANtaK12beb%2Bx4xHgs%3DiQntuXjXb8Gijx2NnfPjcH4OpraDbyuA%40mail.gmail.com.

--

Atenciosamente,
Carlos Alberto Junior Spohr Poletto

carlos.inf.br

[JSL Soluções]

Publiquei no meu repositorio da empresa pois é o unico local publico que da pra colocar pois nao consigo usar o namespace deles e enviar pull request pra ficar parado nem rola. Há alguns caminhos que nós mesmo podemos tomar. Minha empresa tem interesse em manter o projeto ativo e no caso precisaria de mais core commiters. Se a maioria concordar puxamos um fork do projeto, agradecemos a Caelum até o momento pelo que fez e bola pra frente, vamos tocando conforme possível. Eu conheco bem a infra estrutura de código do projeto pois participo desde a versão 2 em bugs entre outras coisas. Querendo ou não esse projeto já tem um curva alta de estabilidade em que poucas funcionalidades podem ser adicionadas e "está pronto". Em questão de licenca como segue Apache2 só o nome teria que trocar para open-vaptor por exemplo e com licenca ainda menos restritiva que inclusive o nome é aberto. 

Se esta dificil dar uma resposta simples do status do projeto imagina o resto. Tudo bem que as prioridades da empresa mudaram, entendo, mas muita gente ainda precisa desse projeto ao minimo atualizado. 

[Carlos Spohr]

De acordo contigo Jonathan.

Vamos mandar um e-mail para o Turini sobre isso, acho que é ele que havia ficado responsável pelo projeto.

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/0c5aba3b-0a96-40ad-bdd6-0c1d74dab0dc%40googlegroups.com.

[Valério]

De acordo. Topo colaborar.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CACvOPWPe_yAsJ_JqaLpiPzY5pj02fd0h8kcb_KWw-pa8vQj_Kw%40mail.gmail.com.

[JSL Soluções]

Oi Pessoal, o VRaptor entrou em um modo de manutenção, vamos pegar apenas bugs de segurança critica. Não vamos trabalhar com o projeto tão cedo. 

Essa foi a resposta em 11 de março. Eu já tentei entrar em contato sem resposta. Se quiserem tentar, por favor me avisem sobre alguma resposta. Por mim já ia abrindo o fork trocando o nome, licenca e criando a versao 1.0. 

[Carlos Spohr]

Acho que seria um bom começo Jonatan.

Vou mandar uma mensagens pros caras também.

On Sun, Apr 19, 2020 at 4:31 PM JSL Soluções <jon...@jslsolucoes.com> wrote:

Oi Pessoal, o VRaptor entrou em um modo de manutenção, vamos pegar apenas bugs de segurança critica. Não vamos trabalhar com o projeto tão cedo. 

Essa foi a resposta em 11 de março. Eu já tentei entrar em contato sem resposta. Se quiserem tentar, por favor me avisem sobre alguma resposta. Por mim já ia abrindo o fork trocando o nome, licenca e criando a versao 1.0. 

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/5f2d7998-029d-4e12-a54d-368c853c15e0%40googlegroups.com.

[Ivo Sestren Junior]

Iniciar um fork seria ótimo.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CACvOPWNXy7DPr0ataxd7V3w2gtKc0%3D6SJs3bv-0ORL-N5smJoQ%40mail.gmail.com.

[João Paulo Linhares Gonçalves]

Será que eles não cederiam o projeto? Não querem manter, mas existem várias pessoas dispostas a manter. Meio irracional o que eles estão fazendo...

On Monday, April 20, 2020 at 10:03:36 AM UTC-3, Ivo Sestren Junior wrote:

Iniciar um fork seria ótimo.

Conectado 20/04/2020 09:03:55, Carlos Spohr <carlo...@gmail.com> escreveu:

Acho que seria um bom começo Jonatan.

Vou mandar uma mensagens pros caras também.

On Sun, Apr 19, 2020 at 4:31 PM JSL Soluções <jon...@jslsolucoes.com> wrote:

Oi Pessoal, o VRaptor entrou em um modo de manutenção, vamos pegar apenas bugs de segurança critica. Não vamos trabalhar com o projeto tão cedo. 

Essa foi a resposta em 11 de março. Eu já tentei entrar em contato sem resposta. Se quiserem tentar, por favor me avisem sobre alguma resposta. Por mim já ia abrindo o fork trocando o nome, licenca e criando a versao 1.0. 

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/5f2d7998-029d-4e12-a54d-368c853c15e0%40googlegroups.com.

--

Atenciosamente,
Carlos Alberto Junior Spohr Poletto

carlos.inf.br

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

[JSL Soluções]

Bom vamos lá.

    Crie um fork em https://github.com/jslsolucoes/trex. O nome passa a ser TRex pois a licença apache2 nao permite uso de nomes, logos, marcas etc. O projeto continua seguindo a mesma licença pois a troca de licenca so pode ocorrer nos arquivos novos então não compensa muito uma alteração muito brusca. Precisamos de um novo logo se alguem se arriscar no design ai. Nesse fork inicialmente foi feito o seguinte.  

• Atualização de todas as dependências do projeto (alguns updates de lib quebram o projeto). Deu pra atualizar bastante coisa. Isso já melhora um pouco a segurança.
• Correções relativas para funcionar em versões mais novas da spec JEE8 e application servers mais novos (Foi testado apenas no wildfly18+).
• Dropado um monte de tranqueira que havia do legado do projeto.
• Introdução de uma Taglib chamada Tagria para componentes de visualização (sempre foi algo muito pedido na comunidade). Existem várias opcoes obvio de view (react,angular,etc) essa só vai ser uma opção default para server side rendering.

O primeiro release esta disponivel em:

 

<dependency>
    <groupId>com.jslsolucoes</groupId>
    <artifactId>trex-webmvc</artifactId>
    <version>1.0.0</version> <!-- Check for latest version on maven repo -->
</dependency>

Daqui pra frente tudo ficara concentrado no repositorio do Github. O código do VRaptor4 é um pouco antigo então tem muita coisa depreciada que precisa atualizar e muita coisa que hoje existe na plataforma JAVA era usado na forma de lib. O framework tem alguns problemas de modularizacao que seria ideal corrigir também pra avançar mais facil no desenvolvimento. Como roadmap inicial penso no seguinte:

• Criar um novo grupo de discussões não acho viável, o ideal é manter tudo no Github atraves de issues.
• Criar uma nova documentação mais simplificada e hospedada no próprio github (branch gh-pages).
• Atualizar todo o código depreciado.
• Suporte a jdk13+ (isso é discutivel, apesar de altamente recomendado. Tem que ver se a comunidade está preparada, por mim já faz).
• Suporte a SelfDeploys como o spring boot só que voltado a plataforma JEE.
• Redirecionar os usuario antigos para o novo fork talvez postando nas proprias issues.
• Refatorar o projeto em modulos menos acoplados e mais coesos depreciando libs antigas ou que hajam substitutas na plataforma JEE ou na propria linguagem.

Bom, vamos tocar conforme for acontecendo as coisas. Preciso de mais gente pra ajudar a gerenciar as issues, questões etc. Se a Caelum se manifestar ou quiser ajudar nesse novo projeto será oportuno. Vamos avaliando esse caminho e mãos a obra (sempre lavando com agua e sabao).

Abraços e qualquer duvidas por favor postar em https://github.com/jslsolucoes/trex/issues

[Renato Resende Ribeiro de Oliveira]

Parece um bom começo.

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/8cf3c0e8-13eb-4539-8a68-4b1bd72ccd21%40googlegroups.com.

[Carlos Spohr]

Boa tarde Renato,

Muito bacana esse seu passo. Vou ajudar no que puder também.

Só gostaria de alinhar um item contigo levando em conta um cenário que tenho nos projetos que participei e volta e meia preciso fazer alguma alteração...principalmente ligados com ERPs.

Como trabalho com aplicações de pequeno e médio porte para vários tipos de sistemas, gostaria de saber se pelo itens que você citou, que tangem a espec da JEE8, JDKs acima da 8 e Wildfly....se ainda irá ter suporte a JDK8 e Tomcat 8.x/9.x?

Pergunto isso, porque há uma grande fatia de mercado que ficam dentro destes caras, e as vezes a migração para o TRex poderia ficar custoso para esse tipo de cliente, mesmo sendo um projeto novo ou até para um upgrade de versões para ter acesso à algumas features pontuais....não sei se consegui ser claro nisso.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNonyPHj2gOqeeta6QuNiQsPy486YjgCZzW8Y8VvN3A%3DrcQ%40mail.gmail.com.

[JSL Soluções]

Carlos,

Essa migração para uma jdk mais nova é bem discutível ainda. Entendo que ainda há muitos projetos e empresas presas no jdk7, jdk8. Não é algo final e todas as funcionalidades e atualizacoes que propus devem ser discutidas antes da efetiva implementação pelas issues do Github. Não queremos perder nem prejudicar ninguem ou nenhum projeto. Temos que alinhar sempre custo benefício e são ótimas suas colocações.

O VRaptor4 já requer spec CDI (que é uma especificacao JEE7+) que geralmente não vem em servlets containers (Tomcat,Jetty) sendo plugada na maioria dos casos com weld-servlet ou com modulos a parte. O natural ao se adotar o VRaptor4 é também já escolher um application servers (TOMee, Glassfish, Wildfly)  que possibilita alem do CDI acesso a mais specs (JPA,JMS,JAX-RS,JAX-WS,etc) e que se integram perfeitamente com o VRaptor4. A proposta de ir para o JDK13 deve obrigatoriamente vir junto com o TRexBoot em que voce vai rodar infraestrutura pronta desses applications servers (começando pelo Wildfly18+), ou seja, você vai pegar seu projeto corrente adicionar um plugin de boot maven (já está em concepção), instalar um jdk13 da vida e dar um java -jar suaplicacao.jar e pronto voce já está atualizado, com um mundo totalmente novo a sua disposição e sem maiores dificuldades. Esse passo importante prove também rodar com maior facilidade aplicações em containers (Docker) e orquestradores (Kubernetes) sem maiores dificuldades.  

Entendo que seja por ai o caminho mas estamos sempre aberto a sugestões e discussões. Em resumo, como prioridade para os proximas etapas, sim continua ainda suportando jdk8+, tomcat, jetty, etc. Prioridade agora é dar um arrumada na casa, atualizar o que puder, remover depreciacao do que puder e desenvolver esse plugin de boot. 

[Carlos Spohr]

Show de bola Jonatan,

Vou aproveitar também e me atualizar um pouco sobre esses caras também.

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/b5150f43-c059-4723-8f39-e30e0cb42a0e%40googlegroups.com.

[Giovanny Brandalise]

Cara muito boa essa ideia!

Eu tinha pensado nela há alguns anos atrás quando usei VRaptor 4 e a Caelum já não estava mais fazendo atualizações.

Na verdade pensei em desenvolver um framework próprio usando as mesmas premissas do VRaptor.

Sobre a lib de view, eu criei um plugin para o VRaptor na época que integra a biblioteca J2Html https://j2html.com/ com a engine de view do VRaptor.

Minha lib foi publicada no repositório de contribuição do VRaptor pelo Turini.

Segue github do plugin https://github.com/gbrandalise/vraptor-j2html/tree/cd6718a15263178f38fa774beb9adca70ee4b6d5

Ainda está muito cru, precisa melhorar muito, e não tive mais tempo de mexer nela, visto que a própria Caelum não estava atualizando o VRaptor, mas achei que essa lib se encaixava bem com a premissa do typesafe do VRaptor e pela questão deles não usarem um lib de view própria, ou seja, usar o jsp mesmo.

Não sei se seria um caminho mais interessante que o Tagria, apesar da maioria da comunidade preferir usar o VRaptor com serviço REST.

Outra coisa interessante seria usar uma lib de verificação de vulnerabilidades nas dependências, não sei se tem alguma coisa assim já pronta para o VRaptor.

Tenho utilizado o Snyk https://snyk.io/ que tem plugin para o maven, porém tem um limite de 200 verificações mensais no plano free, e essas verificações conta para cada lib verificada, então esse valor de 200 alcança rápido.

Mas ele é realmente muito bom, usa os relatórios e conceitos do OWASP, além de gerar relatórios de cada verificação de vulnerabilidades e indicar possíveis soluções. 

De qualquer forma, esse fork me interessa muito.

Vou ficar ligado nas atualizações, e se possível, contribuir com alguns pull requests também.

[Ivo Sestren Junior]

Bom dia.

Aqui eu tenho um projeto com o uso do VRaptor 4 + CDI 2.0 + Thymeleaf

A maioria das coisas está em modulos separados, deem uma olhada.

Qualquer coisa só me chamar.

Link: https://github.com/IvoSestren/strn-ec

Att.

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/aa05cfee-56b9-4cc4-853b-39e7c0561855%40googlegroups.com.

[Caio César Mendonca Souza]

Oi Pessoal, Caio do grupo caelum aqui. 

Eu posso liberar o acesso do vraptor lá github da caelum para quem queira manter o suporte. 

O que vocês acham ? Assim a gente centraliza tudo no repositório oficial. 

abraço

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/Mailbird-c102fa3a-0b37-42bd-bc56-c454f2f647bb%40sestren.com.br.

[João Paulo Linhares Gonçalves]

Eu acho essa a melhor opção, assim mantemos o nome e temos uma
continuidade do projeto.

> Você recebeu essa mensagem porque está inscrito em um tema no grupo "caelum-vraptor" dos Grupos do Google.
> Para cancelar inscrição nesse tema, acesse https://groups.google.com/d/topic/caelum-vraptor/yqN6P5YD5Vg/unsubscribe.
> Para cancelar inscrição nesse grupo e todos os seus temas, envie um e-mail para caelum-vrapto...@googlegroups.com.
> Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAGR0xvVb%3D07Lsa19h2gC6eeh%2B5mMQHp3WoUfrpCnHBKaJUpsNA%40mail.gmail.com.



--
João Paulo L.G.
joaop...@gmail.com

[João Fernandes Lima Neto]

Também acho essa a melhor opção.

Em qui., 23 de abr. de 2020 às 15:21, João Paulo Linhares Gonçalves
<joaop...@gmail.com> escreveu:

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "caelum-vraptor" dos Grupos do Google.

> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

> Para ver esta discussão na web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CA%2BWhBsVX3HKVFVB0H1Ywbhvn2wnqD8b6hyWSMg8y5cw46qPt_A%40mail.gmail.com.

[Caio César Mendonca Souza]

O Jonatas da JSL Soluções cuidar do repositório ?  Acho que podemos começar com apenas uma pessoa cuidando dos PRs e etc, se a demanda aumentar muito a gente pensa em ver mais alguém. 

Que tal Jonatas?

abraço

Para ver esta discussão na web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAFU6mw3WxwUmCK8xSbsZzDLX7LK20%3D1Fygu%3DsF-hikO2%3DZ0v7w%40mail.gmail.com.

[Valério]

É isso.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

[JSL Soluções]

Caio,

Entendo que precise alguem da Caelum alocado nesse projeto no dia a dia (como era o Lucas, Garcia-JJ, etc) colocando novas funcionalidades já que o projeto ainda está sob os braços da empresa (../caelum/vraptor4). Pull request são coisas pontuais que acontecem uma hora ou outra e dependem muito da vontade das pessoas contribuirem, todos sabemos sobre a realidade de quem se propoe a trabalhar com opensource. Sem uma empresa por trás tocando forte ele tende a ficar como está. Acredito que as coisas devem ir alem das atuais, falo numa boa isso. Ainda tendo a manter o hard-fork e quem tiver interesse em migrar para esse novos conceitos serão bem vindos. O bom disso é que já dá pra evoluir pra  jdks mais recentes sem preocupacoes sobre retrocompatibilidade para quem gosta de algo mais "estavel". Pretendo oferecer suporte a um monte de coisa que sempre senti falta e tentar oferecer algum suporte pago (não é prioridade no momento mas é uma opção). Espero que entendam. Só tenho elogios e agradecimentos a fazer a Caelum, mas nesse caso minha opinião é que voces estao pisando na bola com a galera faz algum tempo.

[Renato Resende Ribeiro de Oliveira]

Pra ser bem honesto acredito que com a popularização do Spring Boot eu não usaria VRaptor (ou o novo fork) em projetos novos, uma vez que para modelos de desenvolvimento baseado em APIs e microserviços ele faz um trabalho melhor e de alta qualidade.

Entretanto para os sistemas que ainda utilizam o VRaptor como biblioteca é importante que uma certa manutenção seja realizada, mas acredito fortemente que isso deveria ser feito no repositório oficial.

Se a manutenção básicas para adequar o funcionamento para novas versões do Java e da spec for feita, muito poucas pessoas irão adotar o fork, até porque se não for compatível com códigos feitos para o VRaptor será muito pouco provável que as pessoas façam o trabalho de migração.

E voltando no início da mensagem, se não compensa migrar e para projetos novos já existem frameworks melhores e com mais suporte, por que adotar o fork?

Só estou jogando ideias na mesa para que pensemos qual é o caminho mais adequado.

Att.

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/50b96580-050c-4ab7-8623-773baa6b5d26%40googlegroups.com.

[JSL Soluções]

Justo, concordo que a discussão é saudável.

"Pra ser bem honesto acredito que com a popularização do Spring Boot eu não usaria VRaptor (ou o novo fork) em projetos novos, uma vez que para modelos de desenvolvimento baseado em APIs e microserviços ele faz um trabalho melhor e de alta qualidade."

Para projetos novos realmente não há o que se discutir, existe centenas de caminhos a se adotar, ir para o hard-fork é uma escolha pessoal de cada empresa ou individuo, pois no fim do dia, cada um  sabe onde aperta o seu calo. Querendo ou não VRaptor mesmo com 8+ anos de vida ainda é muito produtivo, simples e rápido de fazer as coisas Entendo que o Spring segue um caminho totalmente diferente da plataforma JEE na qual VRaptor4 se insere. Pra microservicos eu ja nao recomendaria Spring por exemplo e sim a spec JAX-RS. Essa discussao JEE e Spring é extensa e podemos concordar que existem espaço pra duas.

"Entretanto para os sistemas que ainda utilizam o VRaptor como biblioteca é importante que uma certa manutenção seja realizada, mas acredito fortemente que isso deveria ser feito no repositório oficial."

Existem centenas de projetos que foram escritos em cima do VRaptor4, isso é um fato que não dá pra ignorar e é infinitamente mais caro trocar toda uma stack sendo que receber novidades e ao minimo atualização e algum suporte é coerente. Quanto ao repositório oficial se continuar nos moldes de hoje ele morre por si só. Qual o incentivo eu tenho de adotar um framework que conheço sendo que ele não disponibiliza novidades, não atualiza o mínimo,etc ?

 

"Se a manutenção básicas para adequar o funcionamento para novas versões do Java e da spec for feita, muito poucas pessoas irão adotar o fork, até porque se não for compatível com códigos feitos para o VRaptor será muito pouco provável que as pessoas façam o trabalho de migração."

A spec do VRAPTOR se mantem (le se @Controller,Result,etc), não será alterada, portanto não há esforço de migração. Nem faz muito sentido fazer isso. Quando digo spec, são specs internas que o Vraptor usa lib no lugar. Um exemplo: VRaptor4 usa XStream pra XML existe a spec JAXB, VRaptor4 usa Gson para serialização existe a spec JSON/JSON-B entre outras. Manutenção básica é o mínimo requerido, qualquer projeto de software que não se adapta e não se atualiza tende a perder relevância.

"E voltando no início da mensagem, se não compensa migrar e para projetos novos já existem frameworks melhores e com mais suporte, por que adotar o fork?"

Para novos projetos ai cada um adota o  que acha melhor ou convem. A migração de código não vai acontecer nem de spec.  Eu prefiro não ficar preso a uma implementação e adotar a spec JEE, tem gente que gosta de Spring (eu não sou muito fã) e uma das poucas coisas que me da inveja é o spring boot. JEE nunca correu atrás disso (Swarm, Thorntail) estão começando agora nesse mundo. O que proponho serve pro VRaptor4 e pra outros projetos que rodam em cima da plataforma JEE.

Em quinta-feira, 23 de abril de 2020 19:32:28 UTC-3, Renato Resende Ribeiro de Oliveira escreveu:

Pra ser bem honesto acredito que com a popularização do Spring Boot eu não usaria VRaptor (ou o novo fork) em projetos novos, uma vez que para modelos de desenvolvimento baseado em APIs e microserviços ele faz um trabalho melhor e de alta qualidade.

Entretanto para os sistemas que ainda utilizam o VRaptor como biblioteca é importante que uma certa manutenção seja realizada, mas acredito fortemente que isso deveria ser feito no repositório oficial.

Se a manutenção básicas para adequar o funcionamento para novas versões do Java e da spec for feita, muito poucas pessoas irão adotar o fork, até porque se não for compatível com códigos feitos para o VRaptor será muito pouco provável que as pessoas façam o trabalho de migração.

E voltando no início da mensagem, se não compensa migrar e para projetos novos já existem frameworks melhores e com mais suporte, por que adotar o fork?

Só estou jogando ideias na mesa para que pensemos qual é o caminho mais adequado.

Att.

Em qui., 23 de abr. de 2020 às 13:45, JSL Soluções <jon...@jslsolucoes.com> escreveu:

Caio,

Entendo que precise alguem da Caelum alocado nesse projeto no dia a dia (como era o Lucas, Garcia-JJ, etc) colocando novas funcionalidades já que o projeto ainda está sob os braços da empresa (../caelum/vraptor4). Pull request são coisas pontuais que acontecem uma hora ou outra e dependem muito da vontade das pessoas contribuirem, todos sabemos sobre a realidade de quem se propoe a trabalhar com opensource. Sem uma empresa por trás tocando forte ele tende a ficar como está. Acredito que as coisas devem ir alem das atuais, falo numa boa isso. Ainda tendo a manter o hard-fork e quem tiver interesse em migrar para esse novos conceitos serão bem vindos. O bom disso é que já dá pra evoluir pra  jdks mais recentes sem preocupacoes sobre retrocompatibilidade para quem gosta de algo mais "estavel". Pretendo oferecer suporte a um monte de coisa que sempre senti falta e tentar oferecer algum suporte pago (não é prioridade no momento mas é uma opção). Espero que entendam. Só tenho elogios e agradecimentos a fazer a Caelum, mas nesse caso minha opinião é que voces estao pisando na bola com a galera faz algum tempo.

Em quinta-feira, 23 de abril de 2020 16:48:09 UTC-3, Caio César Mendonca Souza escreveu:

O Jonatas da JSL Soluções cuidar do repositório ?  Acho que podemos começar com apenas uma pessoa cuidando dos PRs e etc, se a demanda aumentar muito a gente pensa em ver mais alguém. 

Que tal Jonatas "?

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/50b96580-050c-4ab7-8623-773baa6b5d26%40googlegroups.com.

[Valério]

Apimentando um pouco a discussão e aproveitando o gancho do Jonatas em relação às specs do JEE (que eu também dou preferência - Spring é ótimo, mas como o amigo bem disse é um mundo à parte e cada um faz suas escolhas), a MVC Spec 1.0 teve sua final release em fevereiro (muito recente). Lembro de, lá por 2015, o Turini participar até mesmo das discussões da JSR, e havia uma perspectiva do VRaptor se adequar, com uma versao 5 que seria aderente.

Caso o pessoal que feche contribuir achar interessante, poderíamos avaliar essa hipótese. Parece que já lançaram uma versão ref (Eclipse Krazo), mas ainda está na versão Beta. Curti muito o VRaptor justamente porque é simples, altamente produtivo e basicamente só depende do JEE.

Att,

Valério

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/e15e9763-c0a1-4565-b7e3-59f6612ebd26%40googlegroups.com.

[JSL Soluções]

É lembro dessa discussão de o Vraptor5 implementar a MVC 1.0.

Eu recentemente abri algumas issues lá e alguns pull requests no Krazo da spec MVC 1.0.  Se quiserem ver uma das discussoes: https://github.com/eclipse-ee4j/krazo/pull/126

Eu tenho um projeto em producao usando essa Spec e ainda falta algumas coisas mais fluentes lá, funciona +- mas já é um puta avanço e os caras são meio cabeça dura em relação a alguns assuntos (por exemplo resolucao fluente, resolucao automatica de view, etc). Copiaram algumas nojeiras do Spring na spec, mas da pra contornar e melhorar. Apesar de ser outro assunto (pq ai estamos falando de algo muito maior pra comunidade) eu animaria implementar a spec e tentar corrigir/melhorar todas as deficiencias da spec para ficar mais produtivo. Mas ai caimos no cenario mais competitivo em que se trata de um projeto novo , mas como digo sempre há espaço para todos.

[Valério]

Eu ainda não avaliei a SPEC, nem sei se a mudança no VRaptor seria muito radical (imagino que muito provavelmente essa versão nova não seria retrocompatível com código da 4.x assim como a 4 foi em relação à 3). Lembro do Turini comentar que estavam puxando muito pro Spring, mas isso tem razões até comerciais já que é o mais adotado no mundo e teoricamente facilitaria uma transição.

Mas podemos pensar nisso depois que o grupo estiver formado e um rumo mais claro tiver sido definido.

Att,

Valério

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/3974ffd4-8af5-46cf-9416-92ec6de3bd49%40googlegroups.com.

[JSL Soluções]

Pra quem tiver interesse sobre a Spec.

https://repo1.maven.org/maven2/javax/mvc/javax.mvc-api/1.0-pfd/javax.mvc-api-1.0-pfd-spec.pdf

Por agora vou trabalhando no jee boot  (analogo spring boot) em forma de plugin, já terminei uma versão e devo disponibilizar em breve. Agora vou partir pra parte standalone com live reload pra dev.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

[Paulo Silveira]

oi pessoal

Eu fico bem contente com essa thread super viva.

Acho que se o JSL preferir ir pelo fork, nao vejo nenhum problema.

Se alguem que ja tenha algumas contribuicoes quiser pegar a liderança do projeto, tambem estou bastante comprado! Seria legal ir para o lado do Eclipse Krazo se nao quebrasse compatibilidade.

paulo

[Renato Resende Ribeiro de Oliveira]

Bom, pelo menos dar encaminhamento no PRs e issues que estão abertas no repositório oficial seria uma boa, antes de focar no fork e em novas funcionalidades.

Att.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/06637db3-bc10-49e2-b673-9049e1848bf3%40googlegroups.com.

[JSL Soluções]

Bom vamos pelos dois caminhos então, alguém se compromente a manter o repositorio oficial estável e atualizado sem maiores novidades eu vou caminhar pela implementação da spec MVC 1.0 no fork do TRex dando algum suportando a Spec do Vraptor junto para nao quebrar muito os projetos atuas. Sei que é ambição demais, mas o Vraptor poderia ter sua propria spec que estende da MVC x.x, ou seja, tem tudo que a MVC x.x e mais algumas coisas que não passam pela spec oficial (sempre vai haver coisas do tipo), pois de novo os caras são bem mais conservadores pelo fato de ter muito mais coisa envolvida no processo e não ser algo mais regionalizado. Até me comprometo a propor um draft nesse sentido, o que acham ?

[Renato Resende Ribeiro de Oliveira]

Bom posso ajudar no repositório oficial, porém existe mais alguém que se disponibiliza a ajudar com os PRs, reviews e issues?

Meu tempo é bem limitado, portanto fico meio impossibilitado de assumir isso sozinho.

Att.

Em sex., 24 de abr. de 2020 às 15:00, JSL Soluções <jon...@jslsolucoes.com> escreveu:

Bom vamos pelos dois caminhos então, alguém se compromente a manter o repositorio oficial estável e atualizado sem maiores novidades eu vou caminhar pela implementação da spec MVC 1.0 no fork do TRex dando algum suportando a Spec do Vraptor junto para nao quebrar muito os projetos atuas. Sei que é ambição demais, mas o Vraptor poderia ter sua propria spec que estende da MVC x.x, ou seja, tem tudo que a MVC x.x e mais algumas coisas que não passam pela spec oficial (sempre vai haver coisas do tipo), pois de novo os caras são bem mais conservadores pelo fato de ter muito mais coisa envolvida no processo e não ser algo mais regionalizado. Até me comprometo a propor um draft nesse sentido, o que acham ?

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/f54082df-ce27-4afc-a257-07ce3b771978%40googlegroups.com.

[Carlos Spohr]

Bom dia,

Também tenho o tempo um pouco limitado mas vou auxiliar também.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNon0K%2BSXhg6cQ7SytOTVOj%2BSvZsw9x5A9DFu32J%3Dj7wFOQ%40mail.gmail.com.

[George]

posso te ajudar também no repositório oficial, poderíamos dividir esta responsabilidade 

Em terça-feira, 28 de abril de 2020 03:18:52 UTC-3, Renato Resende Ribeiro de Oliveira escreveu:

Bom posso ajudar no repositório oficial, porém existe mais alguém que se disponibiliza a ajudar com os PRs, reviews e issues?

Meu tempo é bem limitado, portanto fico meio impossibilitado de assumir isso sozinho.

Att.

Em sex., 24 de abr. de 2020 às 15:00, JSL Soluções <jon...@jslsolucoes.com> escreveu:

Bom vamos pelos dois caminhos então, alguém se compromente a manter o repositorio oficial estável e atualizado sem maiores novidades eu vou caminhar pela implementação da spec MVC 1.0 no fork do TRex dando algum suportando a Spec do Vraptor junto para nao quebrar muito os projetos atuas. Sei que é ambição demais, mas o Vraptor poderia ter sua propria spec que estende da MVC x.x, ou seja, tem tudo que a MVC x.x e mais algumas coisas que não passam pela spec oficial (sempre vai haver coisas do tipo), pois de novo os caras são bem mais conservadores pelo fato de ter muito mais coisa envolvida no processo e não ser algo mais regionalizado. Até me comprometo a propor um draft nesse sentido, o que acham ?

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/f54082df-ce27-4afc-a257-07ce3b771978%40googlegroups.com.

[Renato Resende Ribeiro de Oliveira]

Certo, temos três pessoas até o momento então. Como podemos proceder pessoal da Caelum?

Att.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/75bd2efd-8b2d-45a6-8b88-8b236235af14%40googlegroups.com.

[Renato Resende Ribeiro de Oliveira]

Contexto acerca do VRaptor: https://hipsters.tech/monolitos-cultura-e-dia-a-dia-na-alura-hipsters-on-the-road-31/

[Paulo Silveira]

George, Carlos

Demorei mais voltei.

Coloquei o Renato como admin. Ele pode deixar voces como comitters pra gente organizar o repositorio e lancar uma versao mais atualizada.

Se quiserem conversar comigo pra ajudar, fico a disposicao, so me mandar um email diretamente. Se o JSL topar participar seria incrivel tambem.

--
Paulo Silveira
www.caelum.com.br
www.casadocodigo.com.br
www.alura.com.br

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNomLU81ZUT7obxWUst9r-aP5fZpz2nFeS5yw4%3Dn4p2V%3DKQ%40mail.gmail.com.

[JSL Soluções]

No momento estou tocando uma implementação alternativa ao Krazo para o MVC 1.0 (nomeado de open-mvc) -> https://github.com/jslsolucoes/open-mvc/tree/feature-rc1

Ainda não soltei uma release oficial pois o apache cxf tá cheio de bugs e estou aguardando os fixes pelos repositórios oficiais (ja abri algumas issues lá e já arrumaram algumas coisas). Para implementações que usam resteasy ou jersey já está funcionando e honrando o TCK da Spec. 

A ideia dessa implementação alternativa é ter um pouco mais de liberdade quanto aos caminhos da Spec que não são nem um pouco flexiveis na spec e implementação oficial. Quando abrir uma release eu vou TENTAR bater um papo com os caras sobre a Spec, pois senti falta de muita abstração que já deveria vir na propria especificação, isso pra definição atual sem colocar nada novo. 

Bom pra adiantar, acho extremamente dificil manter compatibilidade entre a Spec MVC 1.0 e o Vraptor4 sem quebrar as coisas. Pelo que entendo o que da pra fazer é suportar algumas features do Vraptor na implementação, no melhor caso:

• Os eventos a propria implementação já suporta algumas (BeforeController,AfterController,BeforeView,AfterView) teria que ver quais mais o Vraptor suporta pra complementar.
• Serializações (xml,json,etc) a propria spec JAX-RS já possui todo suporte para fazer, entao não faz muito sentido manter esses submodulos this.result(Results.json|xml()).serialize(). O que da pra fazer é melhorar o suporte a isso, pois a plataforma tem deficiencia com filters (includes,excludes que o vraptor suporta).
• Injecao de dependencia já vem suportada pela spec CDI no JAX-RS na maioria dos casos (exceto cxf) entao nao muda muita coisa, pq a implementacao contorna isso.
• A interface fluente do VRaptor da pra suportar com limitacoes relativas ao forward.
• Toda parte de validation, binding e mensagem de erros tem um jeito próprio que a Spec define, se assemelha ao que o Vraptor faz.
• Converters deriva da spec JAX-RS mas é parecido também.
• Interceptors já vem suportada pela spec CDI também. 

Em resumo, temos um drama. Não sei muito o que pensar sobre os caminhos. O que tenho em mente é terminar a implementação suportando o maior numero de application servers (6 atualmente), melhorar filters de serializacao, componentes básicos de transacao com JPA, email, scheduler, build para container já tudo integrado e avançar nesse sentido. 

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/75bd2efd-8b2d-45a6-8b88-8b236235af14%40googlegroups.com.

--

Renato Resende Ribeiro de Oliveira
Senior Software Engineer @ Edvisor.io
MSc - Computer Science - Universidade Federal de Lavras

PMP - Project Management Professional

Skype: renatorro.comp.ufla.br

LinkedIn: https://www.linkedin.com/in/renatorro

--

Renato Resende Ribeiro de Oliveira
Senior Software Engineer @ Edvisor.io
MSc - Computer Science - Universidade Federal de Lavras

PMP - Project Management Professional

Skype: renatorro.comp.ufla.br

LinkedIn: https://www.linkedin.com/in/renatorro

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNomLU81ZUT7obxWUst9r-aP5fZpz2nFeS5yw4%3Dn4p2V%3DKQ%40mail.gmail.com.

[Valério]

Show de bola, é o VRaptor voltando à vida.

Tempo anda meio escasso, como o da maioria aqui, mas topo ajudar como commiter.

Abraço,

Valério

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/c7f87409-4a39-48ca-9dd3-7ff5d0dde56co%40googlegroups.com.

[Eduardo]

Só uma dúvida, seria um caminha viavel ter o vraptor sobre o mvc (krazo)? seria um vraptor 5 para não quebrar a compatibilidade e implementando funcionalidade adicionais para trazer mais proximo da facilidade que é usar o vraptor? muitos coisas já estariam implementadas no mcv

[JSL Soluções - Consultoria em Tecnologia]

O problema é justamente fazer um rodar sobre o outro, conceitualmente são muito diferentes. O Vraptor se assemelha mais ao Spring no pattern do que ao Krazo que é feito em cima das especificacao JAX-RS. Por exemplo, fui implementar convenção em cima de um controller do Krazo, é um parto a especificação te bloqueia em um monte de coisa tem que fazer varias gambiarras pra tentar chegar perto de algo semelhante. O krazo internamente não é mil maravilhas em termos de flexibilidade, argumentei com os caras, mas ta la parado A de eterno. Sinceramente isso é umas das coisas desanimadoras em alguns open source, é um parto mudar ou discutir pra mudar ou melhorar algo com threads extensivas que ficam discutindo nome de variavel ao inves de discutir design de todo sua solucao. A plataforma entrega as mesmas coisas de jeitos distintos como falei alguns posts atras, entao sobra muita pouca coisa que o Vraptor vá contribuir em termos de facilidade. Compensa mais avancar ele no modelo em que está desenhado corrigindo deficiencias e evoluindo do que tentar compatibilizar com a spec mvc. 

[Renato Resende Ribeiro de Oliveira]

Iniciamos essa semana a conversa sobre próximos passos para o VRaptor e para a versão 4.3.0 final estamos planejando:
- Compatibilidade com CDI 2
- Correções de issues e encaminhamento dos pull requests abertos

- Atualização de bibliotecas.

Para outras versões ainda estamos em discussões sobre qual caminho tomar.

Se mais alguém tiver interesse em participar desses trabalhos me envie um e-mail que convido para se juntar às discussões.

Att.

--

Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/e19ae5f4-c7cf-45d9-9e57-9ad163a9a474o%40googlegroups.com.

[Paulo Silveira]

Renato, quando tiver mais noticias seria otimo! Excelente se tivermos essa 4.3.0

--
Paulo Silveira
www.alura.com.br

www.caelum.com.br

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/caelum-vraptor/CAMSDNokVi%3DhkegN%3DwZC3CqoQ7ksfm%3DSLugsdwdvZ21jN0cK7mw%40mail.gmail.com.

[Antonio Elizeu da Rocha]

Tem alguma previsao?

[joaop...@gmail.com]

Pessoal que estava tocando para sair a versão 4.3.0, teve algum avanço? Falta muito?