<div dir="ltr">I was wondering the same thing; just from looking at it from the outside, being after Alpha1 seems like the right time to do this kind of update.<div><br></div><div>Also is there any public schedule available for WF 11 and 12? It'd be sad if we could get BV 2 into WF only in a year or so (wildly guessing here when to expect WF 12), while e.g. Spring 5 with BV 2 support is planned to be released this summer.</div><div><br></div><div>--Gunnar</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-14 18:38 GMT+03:00 Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1.<br>
<br>
Where are the Alphas (aside from Alpha1), the Betas, the CRs for WildFly<br>
11 ?<br>
<br>
Tristan<br>
<span class=""><br>
On 7/13/17 7:06 PM, Emmanuel Bernard wrote:<br>
> Barring other constraints, I would think we would want to move forward<br>
> to the latest in the next WF major. What’s the point of holding up<br>
> technology? Likewise there is very little value in keeping the old one<br>
> in in parallel. More knobs and more pain in the subsystems.<br>
><br>
>> On 13 Jul 2017, at 10:50, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a><br>
</span><div><div class="h5">>> <mailto:<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> <TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0,<br>
>> or should new modules be added for those, letting the user to choose<br>
>> the version to enable?</TL,DR><br>
>><br>
>> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like<br>
>> to discuss how BV 2 and its reference implementation HV 6 can be<br>
>> integrated into WildFly. BV 2 will be part of Java EE 8.<br>
>><br>
>> I can think of two approaches:<br>
>><br>
>> 1) Just updating the existing WildFly modules for BV API and HV to the<br>
>> new versions<br>
>> 2) Leave the existing modules for BV 1.1 (+ implementation) and add<br>
>> separate modules for BV 2.0<br>
>><br>
>> 1) would be easier and less effort. But I'm not sure how feasible it<br>
>> is, in case that WF should remain Java EE 7 compatible for the time<br>
>> being. Also, while BV 2 is fully backwards compatible at the<br>
>> spec-level, Hibernate Validator amends the spec API with some extended<br>
>> functionality. In that extended HV-specific API some changes were<br>
>> required, mostly as previous experimental features were replaced by<br>
>> equivalent standardized functionality in the BV API.<br>
>><br>
>> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail<br>
>> some more work:<br>
>><br>
>> * A place for that configuration is required. I think it could be done<br>
>> similarly to JPA, i.e. via a property with the module name in<br>
>> META-INF/validation.xml<br>
>> * Depending on that configuration, the right set of modules needs to<br>
>> be enabled. Several modules currently have a fixed dependency to the<br>
>> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy)<br>
>> which would have be made more dynamic, based on the version chosen by<br>
>> the user.<br>
>><br>
>> What does everyone think on this? And what could be a suitable WildFly<br>
>> target version for such change? Could we aim at incorporating BV 2.0<br>
>> into WF 11?<br>
>><br>
>> Thanks,<br>
>><br>
>> --Gunnar<br>
>><br>
>> [1]<br>
>> <a href="http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/" rel="noreferrer" target="_blank">http://beanvalidation.org/<wbr>news/2017/07/12/bean-<wbr>validation-2-0-cr3-submitted-<wbr>to-final-approval-ballot/</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> wildfly-dev mailing list<br>
</div></div>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.<wbr>jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
<span class="im HOEnZb">><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
><br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></div></div></blockquote></div><br></div>