Hi, We still seem to have a disagreement about the benefits/wisdom of exposing a service which merges resources. I have an alternative which I think solves for both the desire to have flexible resource selection algorithms and not expose resources outside the context of the ResourceResolver.
We create a SPI interface called MergedResourceSelector. This has a single method: Iterator<Resource> selectResourcesToMerge(ResourceResolver, String) OSGi services implementing this interface must also have a merge.root service property. In the resource merger bundle, we have a whiteboard which listens for these services and, for each, it registers a ResourceProviderFactory which references the Selector service and uses the merge.root service property for the provider.roots property of the ResourceProviderFactory. The ResourceProvider is an implementation detail of the resourcemerger bundle. This is essentially what I'm trying to implement anyway (where the AbstractMergingResourceProvider has all of the merging logic) for SLING-3657; the only difference is that rather than using a class hierarchy, we use OSGi services. WDYT? Justin
