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