[ https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053411#comment-17053411 ]
Konrad Windszus commented on JCRVLT-403: ---------------------------------------- With JCRVLT-417 the intermediate folders having no explicit primary type given should now be the default type (i.e. sling:Folder within a sling:Folder parent). As `/apps` in AEM is a `sling:Folder` all intermediate nodes in the future should be of that type by default as well. Still the problem exists with older FileVault version which always created nt:folder as default intermediates. With the strict application package type, there is no way to enforce the intermediate node type... > 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)