[bv-dev] Questions on TCK SequenceResolutionTest

[Emmanuel Bernard]

Gunnar is expressing the intent correctly as far as memory serves. I did want a *non ambiguous* partiall order behavior in sequences. The example makes it ambiguous. 

But groups and group sequences are probably in the top 3 of the most complicated piece of specification in the whole Java EE ecosystem. Not proud of it but it works as expected for all real life code of which thus test is not a representative :)

Emmanuel

> On 30 Mar 2018, at 15:48, Matt Benson <mbenson at apache.org> wrote:
> 
> I think the issue is that Guillaume and I are viewing the group sequence as a simple, ordered set of instructions, whereas you, Gunnar, are viewing it more as a dependency graph. I will confess that I am having difficulty rising to your challenge of providing an example that would be indisputably cyclical without having sat down at a computer or with pen and paper to postulate one. In the meantime I wonder if there is anything in the spec to encourage this "dependency graph" interpretation of what a group sequence is. Having said that, it is probably true that a user who had set up such a situation as this had done so unintentionally. OTOH, the second attempt at validating the time consuming checks would be a noop in any case.
> 
> Matt
> 
>> On Fri, Mar 30, 2018, 8:36 AM Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>> On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> If not that, what else would you consider as a cycle in the context of group sequence definitions then?
>>> 
>>> This sequence definition here says: "validate TimeConsumingChecks *before* TestEntity" and "validate TimeConsumingChecks *after* TestEntity", aborting after the first group found with violated constraints. There's no way to implement this.
>> 
>> Not saying it makes sense but I could imagine validating TimeConsumingChecks then TestEntity then TimeConsumingChecks again.
>> 
>> If we consider this a cyclic dependency, then the test is indeed valid. The name is not very descriptive but it's not wrong either.
>> 
>> -- 
>> Guillaume
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180330/2c07ef16/attachment.html