[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026237#comment-17026237
]
Konrad Windszus edited comment on JCRVLT-403 at 2/18/20 9:59 AM:
-----------------------------------------------------------------
[~dsuess] I still don't know who is supposed to provide the package for
ancestor nodes for overlays in case of
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.
Both is in apps (customer owned), but in fact it is provided by two different
3rd parties (who don't know about each other). What would be the right approach
for the overlay in acs-aem-commons for enforcing a certain ancestor node type
different from the default (nt:folder)?
In fact this requires the ancestor nodes to be of type != nt:folder. Are you
suggesting that both packages in this case should include the ancestor
.content.xml to make sure the parent node is of type sling:Folder?
Update: I use the pattern
{code}
<filter root="parent of overlay node">
<include pattern="parent of overlay node">
<include pattern="path of overlay node(/.*)?">
</filter>
{code}
to enforce the least restrictive node type "sling:Folder" on the parent node of
the overlay which requires setting arbitrary properties.
This works well, even in cases the {{parent of overlay node}} does already
exist with the wrong type (e.g. nt:folder) in the repo, because during
installation the node type will be changed to the less restrictive
{{sling:Folder}}. As for those cases the other properties on the parent node do
not really matter, this approach works really well, but violates the rules for
application packages.
was (Author: kwin):
[~dsuess] I still don't know who is supposed to provide the package for
ancestor nodes for overlays in case of
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.
Both is in apps (customer owned), but in fact it is provided by two different
3rd parties (who don't know about each other). What would be the right approach
for the overlay in acs-aem-commons for enforcing a certain ancestor node type
different from the default (nt:folder)?
In fact this requires the ancestor nodes to be of type != nt:folder. Are you
suggesting that both packages in this case should include the ancestor
.content.xml to make sure the parent node is of type sling:Folder?
> 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)
