[
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789549#comment-17789549
]
Konrad Windszus edited comment on JCRVLT-733 at 11/25/23 6:25 PM:
------------------------------------------------------------------
Although the proposed format outlined above for a properties file containing
type information for certain paths works well for validation purposes, it
shouldn't be necessary to use that within content packages. Instead content
packages should only consider a new import option for uncovered ancestors (with
CREATEWITHPROPERTIES being the default). The actual types should still be in
DocView XML files (where only the properties for {{jcr:primaryType}} and
{{jcr:mixinTypes}} are considered).
was (Author: kwin):
Although the proposed format outlined above for a properties file containing
type information for certain paths works well for validation purposes, it
shouldn't be necessary to use that within content packages. Instead content
packages should only consider a new import option for uncovered ancestors (with
CREATE being the default). The actual types should still be in DocView XML
files (where only the properties for {{jcr:primaryType}} and {{jcr:mixinTypes}}
are considered).
> Allow to enforce ancestor primary and mixin type
> ------------------------------------------------
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node:
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns
> which override the full ancestor node (but not arbitrary children). This
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing
> a common ancestor. There is often no dependent package which just provides
> the common ancestor (as that would also overwrite the full subtree).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
