jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-817) TCK vs available property types
Date Tue, 27 Mar 2007 12:52:32 GMT

    [ 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.


Mime
View raw message