You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2007/03/27 14:52:32 UTC

[jira] Commented: (JCR-817) TCK vs available property types

    [ https://issues.apache.org/jira/browse/JCR-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484445 ] 

Julian Reschke commented on JCR-817:
------------------------------------

After discussing this with Marcel, the new proposal is to have the affected test cases explicitly check that the store allows setting the property to the desired type, and if it doesn't, thow an NotExecutableException (we want a convenience method in AbstractJCRTest, so that the code required to check isn't duplicated all over the place).


> TCK vs available property types
> -------------------------------
>
>                 Key: JCR-817
>                 URL: https://issues.apache.org/jira/browse/JCR-817
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: JCR TCK
>            Reporter: Julian Reschke
>            Priority: Minor
>
> The TCK tests allow configuration of node type / property names to tests specific property types, but they do not take into account that a given repository may not support a specific property type (this is similar to issue JCR-801 about multiple workspace support).
> JSR-170 is a bit fuzzy here: it requires all types, but does not require that every type actually exists on a settable node type. In practice, a repository may support reference properties on the builtin nodetypes for version storage, but nowhere else.
> Thus, there should be a way to configure the tests so that specific property type tests are left out. Again, there are a few possibilities to do that:
> 1) reserve a special property name for the case where the test should be skipped ("PROPERTY_TYPE_NOT_SUPPORT"), or
> 2) add new config flags.
> The latter arguably is the cleaner approach, the former avoids introducing new configuration parameters. Thus, I'm leaning to 2). Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.