[
https://issues.apache.org/jira/browse/JCRVLT-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated JCRVLT-479:
----------------------------------
Summary: jackrabbit-nodetypes validator: validation fails "overeager" for
protected properties (was: jackrabbit-nodetypes validator: validation fails
"overeager" for protected node types)
> jackrabbit-nodetypes validator: validation fails "overeager" for protected
> properties
> -------------------------------------------------------------------------------------
>
> Key: JCRVLT-479
> URL: https://issues.apache.org/jira/browse/JCRVLT-479
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Affects Versions: 3.4.6
> Reporter: Stefan Seifert
> Priority: Major
>
> having a property node type definition defined for validation (e.g. from
> [https://github.com/Netcentric/aem-nodetypes]) may lead to problems when the
> node type definition contains properties defined as autocreated.
> example:
> {noformat}
> [cq:Tag] > mix:title, nt:hierarchyNode
> orderable
> - * (undefined) multiple
> - * (undefined)
> - sling:resourceType (string) = 'cq/tagging/components/tag' mandatory
> autocreated
> + * (nt:base) = cq:Tag version
> {noformat}
> the problem is that a package exported from the repository usually contains
> this property and then the validation fails (although the property has
> exactly the value given as default value here). leading to a failed build
> with:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Property
> 'sling:resourceType' [String] is not allowed in node with potential default
> types [cq:Tag]: Property is auto-created and can not be manually added",
> filePath=jcr_root\content\_cq_tags\sample\.content.xml,
> nodePath=/content/cq:tags/sample, line=6, column=52
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/sample-content
> the code currently has a hardcoded list of properties to ignore this behavior
> ({{jcr:primaryType}}, {{jcr:mixingTypes}}). but this does not help for other
> properties. i'm wondering if this validation is really helpful or should be
> removed or disabled? alternatively the list of allowed protected properties
> could be made configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
