[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023385#comment-17023385
]
Tobias Bocanegra commented on JCRVLT-403:
-----------------------------------------
the {{tool-ancestor}} is given by the system. it provides
{{/apps/cq/core/content/nav/tools/security}} for example.
and {{tool-ancestor-foo}} would need to depend on {{tool-ancestor}} etc...
bq. 1. How does tool-ancestor-... define the ancestor nodes without using
include/excludes?
just as filter root. introducing excludes/includes was IMO a big mistake. it
would have been so much easier, if we just have complete sub-tree replacements.
bq. 2. What is the right installation order? tool-foo and tool-bar don't know
about each other and the ancestor packages will overwrite each other!
tool-foo and tool-bar need to reside on different subtrees. and their ancestor
package is provided by the system.
> 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)
