IMO the biggest difference is how this defines the root of the dynamic resources, e.g. via creating a resource at that path or providing a configuration with the source and target. This alone is a major advantage as it means that ddr configurations can be defined at runtime with a composite store.
The problem I see here is that we are trying to solve the same problem multiple ways. My take on the problem is: As a developer or superuser, I want to be able to present a virtual tree of resources generated from a tree of resources and a configuration tree. Resource merger solves this problem by anchoring a root and then defining source paths which can be overlayed and configured in order. This works well in the case where you have only two trees and you want to present a merged copy of these two trees, but does not work for arbitrary anchor points. Superimposing supports creating arbitrary roots but these roots can only be tied to one source. It also only allows overriding the overlayed resouces by using a lower level api (such as JCR) because the sling post servlet will update the source resources. Generally, I think it's better to have fewer ways of doing the same thing, do it makes sense to consolidate if possible. Given that resouces merger is widely used, I can't see how it would be worth the effort to regression check potential breaking issues. However, given that SuperImposing has not been significantly updated in years, I would recommend that we: 1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12 2. Update SuperImposing to support defining virtual trees by source and source+target and other DDR features 3. Define a feature model to install the bundle and create an oak index for the mixin 4. Release this as the 1.0 version of SuperImposing I've already taken a run at updating SuperImposing and am ~75% there. What do others think? -Dan On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer <[email protected]> wrote: > Here is a short recap after trying to compare Superimposing Resource (SIR) > and the Declarative Dynamice Resource (DDR). They are similar in some > respect and different in others: > > Feature SIR DDR > > Resource Resolver type Admin RR Service RR > Linking from Target Source > Mixin Supported Not > Supported > Resource Changes Supported Supported > Property Changes Not Supported Supported > Configure Parent by > 1st Level Child Supported Not Supported > Overlays Supported > Not Supported > 2nd Level Redirection Not Supported Supported > Filtering (Security) Not Supported Supported > Java 11 Not Supported Supported > Sling 12 Not Supported > Supported > > Cheers - Andy > > > On Apr 20, 2021, at 6:13 AM, Stefan Seifert > > <[email protected]> > wrote: > > > > hello ruben. > > > > use case sounds a bit similar to > > > > https://github.com/apache/sling-org-apache-sling-superimposing (a bit > outdated) > > and > > https://github.com/apache/sling-org-apache-sling-resourcemerger > > > > can you differentiate what DDR does differently? > > > > stefan > > > >> -----Original Message----- > >> From: Ruben Reusser <[email protected]> > >> Sent: Tuesday, April 20, 2021 1:54 PM > >> To: [email protected] > >> Subject: Re: Sling Declarative Dynamic Resources > >> > >> totally forgot to add the link to the code base - sorry > >> > >> > https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr > >> > >> On 4/19/2021 10:29 AM, Ruben Reusser wrote: > >>> dear sling community > >>> > >>> Andreas has been working to create a way to dynamically create > >>> component proxies in Sling based on a configuration. In peregrine-cms > >>> we are planning to use this approach when a new tenant (a new website) > >>> is created by a user. It allows us to proxy the base components into a > >>> new /apps folder for the website. A super user for the site can then > >>> potentially change the title/group of a component and the default > >>> structure that is used when adding a component to a page. > >>> > >>> We hope this component may be useful to other sling based content > >>> management systems as well. We'd like to ask to move this module out > >>> of the whiteboard - but of course we welcome any > >>> comments/concerns/things we should consider to make sure everybody can > >>> benefit from this module. > >>> > >>> looking forward to your comments! > >>> > >>> Ruben > > > >
