[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026049#comment-17026049
]
Dominik Süß commented on JCRVLT-403:
------------------------------------
[~kwin] - looking at AEM as example the discussion about given structures is
more or less virtual as the paths are split up in libs (vendor owned) & apps
(customer owned). Repoinit is being used to define the root nodes (e.g. apps)
so a customer may easily define apps in a repository-structure package as given
by the system. It is up to the ones maintaining the structures to make sure to
not change them in backwards incompatible way (e.g. incompatible nodeTypes) in
the future.
As special scenario arises for the case of overlays as overlays would be spread
over the tree and people would not really care about the parent structures that
in case of overlays mostly are about nt:Folder or sling:folder nodes (or maybe
nt:unstructured). As long as it IS nt:folder one may just rely on the implicit
creation via parent path and declare the parent structure as given by the
system via repository structure package.
As soon as the corresponding ancestor node in libs is other than nt:Folder
there is a chance that another overlay later on will depend on that node type
to be set or even the overlay itself as nt:folder might break functionality -
therefore it is curcial in such a case to have either a package which defines
this node (and this should only be one package or duplication will eventually
run out of synch) OR the structure is being defined via repoinit (again as
single source of truth) in which case the structure would be reflected in the
repository structure package for the ancestor check not to fail.
> 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)
