Hi Matt,

On Tue, Mar 13, 2018 at 12:18 AM, Matt Benson <mbenson@apache.org> wrote:

Hi all,
This issue could be similar to my last one. On #testValidOnListAndOnTypeArgumentWithGroupConversions() the expectation is the single violation on visitors[0].name with the Default group. My implementation converts Default to ExtendedChecks1, cascades the legacy list elements, then converts ExtendedChecks1 to ExtendedChecks2 when cascading the type parameters. I end up with violations on visitors[0].extended1 and visitors[0].extended2 . I don't see any interpretation that seems to justify triggering the violation on the Default group. The test points to spec section 5.1.3 but a reread of that section does nothing for me here. Help would be appreciated here.

I think you're right. I remember some discussion with Gunnar about this specific subject when we decided to only keep the group conversion of the type arguments but it's definitely not specified as is in the spec.

Considering it's a corner case that is explicitly not recommended, I think we should simply drop this test and keep the behavior undefined for now and do better in the next revision of the spec.

Reading again this part, I think the "(in order to prevent the container elements from being validated twice)" part should also go away as it's at the discretion of the implementation to validate them twice or once (especially given we have some infinite loop detection going on to prevent circular dependencies that might intervene and IIRC we also don't want constraints to be enforced twice).

Gunnar is at a conference right now, we'll discuss that more in depth when he's back but I'd say don't worry about this test.

About the TCK tests being ignored, could you please open another thread with more details on your TCK setup (pointers to the code and how you run it would be nice) so we don't pollute this one?

Thanks.

Guillaume