<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Barring other constraints, I would think we would want to move forward to the latest in the next WF major. What’s the point of holding up technology? Likewise there is very little value in keeping the old one in in parallel. More knobs and more pain in the subsystems.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 13 Jul 2017, at 10:50, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" class="">gunnar@hibernate.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class=""><TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable?</TL,DR></div><div class=""><br class=""></div><div class="">The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8.</div><div class=""><br class=""></div><div class="">I can think of two approaches:</div><div class=""><br class=""></div><div class="">1) Just updating the existing WildFly modules for BV API and HV to the new versions</div><div class="">2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0</div><div class=""><br class=""></div><div class="">1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API.</div><div class=""><br class=""></div><div class="">2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work:</div><div class=""><br class=""></div><div class="">* A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml</div><div class="">* Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user.</div><div class=""><br class=""></div><div class="">What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">--Gunnar</div><div class=""><br class=""></div><div class="">[1] <a href="http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/" class="">http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/</a></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">wildfly-dev mailing list<br class=""><a href="mailto:wildfly-dev@lists.jboss.org" class="">wildfly-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</div></blockquote></div><br class=""></div></body></html>