You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2017/10/20 04:29:00 UTC

[jira] [Commented] (JCRVLT-216) Aggregate defined children of the filter path ancestors, optionally install them

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