Hi, I am reactivating the thread as we really would like to successfully mutualize the merging of resources [1] in some particular cases as well. The following use case [0] implies:
- Merging of two semantically related resources that do not share a relative path - The location of the two resources is not limited to the search paths as they will be located under <config>, <etc/design>, <libs> and <apps> - The resources are not components as they only are a tree of resources representing configurations - Currently some useful classes from <org.apache.sling.resourcemerger.impl> and containing the merging logic are not publicly accessible such as <MergedResource> or <MergedValueMap> What could or should we do to achieve our goal ? [0] https://jira.corp.adobe.com/browse/CQ-88886 [1] https://jira.corp.adobe.com/browse/CQ-49953 Cheers, Patrick Fauchère Software Engineer Adobe Barfüsserplatz 6 CH-4051 Basel, Switzerland +41 (0)61.226.57.62 (tel), +41 (0)78.613.47.66 (cell) [email protected] www.adobe.com On 6/17/16, 10:47 AM, "Christanto Leonardo" <[email protected]> wrote: >Hi, > >I would say using prefix (e.g. /mnt/merge) is not a problem. > >Cheers, >Christanto > > > >On 17/06/16 00:34, "Justin Edelson" <[email protected]> wrote: > >>The thing with the path prefix is one of circularity. If you say >>/content/resource2 is the merging of /content/resource2 and >>/content/resource1, then you have an endless loop of merging. So we have >>to be able to say that <someotherpath> is the merge of those two >>resources. And that other path needs to contain the “start point” for >>the merging (i.e. /content/resource2 in this case). >> >>There’s no duplicated nodes. The Sling Resource Merger makes generic >>what can be generic (i.e. the actual merging logic) while leaving the >>part that can’t be (i.e. the identification of resource to be merged) >>open for pluggability. >> >>Justin >> >>On 6/16/16, 6:10 PM, "Gabriel Walt" <[email protected]> wrote: >> >> >>Yes. >> >>It would be great to have a generic Sling feature to virtually merge >>trees, in order to avoid duplicating nodes when it doesn’t make sense. >> >>Maybe overlays are not intended for that? But on the other hand, we use >>that already for merging dialogs of sling:resourceSuperTypes, which is a >>very similar use-case. It would however be nice if the resource merger >>could be used for any tree that refers to another tree with a specific >>property. >> >>Gabriel >> >> >>On 16/06/16 23:57, "Justin Edelson" <[email protected]> wrote: >> >>By “strongly limited” do you mean requiring a path prefix? >> >> >> >>On 6/16/16, 5:56 PM, "Gabriel Walt" <[email protected]> wrote: >> >> >>Are you aware of any particular reason why overlays are so strongly >>limited? Because this typically doesn’t allow to have overlays within >>the same path, and makes it impossible for any arbitrary resource to act >>as overlay of another resource it would reference. >> >> >> >>On 16/06/16 23:33, "Justin Edelson" <[email protected]> wrote: >> >>Hi Gabriel, >>Sling merging can’t do that exactly, but it could do >> >>/mnt/merge/content/resource1 >> @sling:overlay = “/content/resource2” >> * header >> @jcr:title = “Hello World!” >> * foo … >> >>i.e. right now, there must be some kind of path prefix. >> >>Regards, >>Justin >> >> >> >> >
