[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022756#comment-17022756
]
Konrad Windszus commented on JCRVLT-403:
----------------------------------------
If that 3rd package is not containing any excludes it may overwrite the node
"foo" and "bar" during reinstall.
Also the problem often is that tool-foo and tool-bar come from different
vendors.
Just think about acs-aem-commons
(https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/master/ui.apps/src/main/content/jcr_root/apps/cq/core/content/nav/tools/acs-commons)
and e.g.
https://github.com/Netcentric/accesscontroltool/tree/develop/accesscontroltool-apps-package/src/main/jcr_root/apps/cq/core/content/nav/tools/security/actool.
If both provide their own package for the ancestor nodes, they will overwrite
each other (if no excludes are used!)
> Clarify usage of package type "application" for overlays
> --------------------------------------------------------
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Konrad Windszus
> Priority: Major
> Fix For: 3.4.4
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
