[
https://issues.apache.org/jira/browse/JCRVLT-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212140#comment-16212140
]
Tobias Bocanegra commented on JCRVLT-216:
-----------------------------------------
I don't think this is a good behavior, since it might install content that is
not expected. also it would be difficult to uninstall the package later,
because the extra content is not recorded in the snapshot. the current
behaviour with creating the ancestors automatically is already a problem in a
lot of cases (I wish we never implemented it :-) as it can have unexpected side
effects.
also, in your example a above, the jcr:content is not a mandatory child node of
a cq:Page, so I don't see why this is a problem?
> Aggregate defined children of the filter path ancestors, optionally install
> them
> --------------------------------------------------------------------------------
>
> Key: JCRVLT-216
> URL: https://issues.apache.org/jira/browse/JCRVLT-216
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Reporter: Nicolas Peltier
>
> When a package is defined with a filter /content/foo/bar and foo has in its
> nodetype children definition some expected node, would be nice to aggregate
> them, with some special flag
> At install time, if the flag is here and target content doesn't have the
> child, then install it.
> Use case in AEM is /content/foo/bar being a tree of pages we are interested
> in, and being able to build a package only with /content/foo/bar filter, not
> /content/foo/bar
> /content/foo/jcr:content
> when you know the problem it's relatively quick to workaround, when you don't
> it always waste some time debugging why all is broken because /content/foo
> doesn't have a content child.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
