Hi Carsten,
Thanks for the explanation, however I fail to see the limitation for only one 
(non-global) region in 
https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/master/docs/api-regions.md.
In general the extension in the feature model allows for arbitrarily many 
regions.

Similarly 
https://github.com/apache/sling-org-apache-sling-feature-apiregionssupports has 
support for a regions.properties which seems to support arbitrarily many 
regions as well.
Also the Resolver Hook seems to be able to filter across arbitrarily many 
regions 
(https://github.com/apache/sling-org-apache-sling-feature-apiregions/blob/47a9f99d17b3558709f0d82ce0d066007f59cfba/src/main/java/org/apache/sling/feature/apiregions/impl/ResolverHookImpl.java#L61).
There is even a test case for 3 regions (1 global + 2 custom ones) in 
https://github.com/apache/sling-org-apache-sling-feature-apiregions/blob/47a9f99d17b3558709f0d82ce0d066007f59cfba/src/test/java/org/apache/sling/feature/apiregions/impl/ResolverHookImplTest.java#L600
Any additional pointers regarding the limitation of regions would be 
appreciated.
Thanks,
Konrad


> On 29. Oct 2024, at 03:55, Carsten Ziegeler <[email protected]> wrote:
> 
> I think the underlying problem is that currently api regions only allow for a 
> single child region - which means that only a single region (leave) is 
> isolated from the others.
> 
> We would need to allow more than one child region - which then allows to have 
> a single global region and for example two isolated child regions for two 
> applications. Both app regions inherit everything from global but they do not 
> share anything with the other app region.
> 
> I haven't looked in detail, but I assume this requires a breaking api change 
> in feature-extension-apiregions to support this on the Java API level. It 
> also requires a different format in the JSON extension to declare this and 
> then finally an implementation in extension-apiregions to support this.
> 
> This change might then come with further changes downstream, e.g. the feature 
> maven plugin.
> 
> Regards
> Carsten
> 
> On 28.10.2024 11:57, Konrad Windszus wrote:
>> This topic was briefly discussed during the Sling Hackathon 
>> (https://cwiki.apache.org/confluence/x/i45yEg).
>> It seems that the best way forward is to no longer rely on the global region 
>> but rather on completely isolated/separated API regions.
>> Is there anything which would need to be extended in either 
>> https://github.com/apache/sling-org-apache-sling-feature-apiregions or in 
>> https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/tree/master
>>  to support this?
>> Thanks,
>> Konrad
>>> On 13. May 2024, at 19:12, Konrad Windszus <[email protected]> wrote:
>>> 
>>> Hi,
>>> I have a question about 
>>> https://github.com/apache/sling-org-apache-sling-feature-apiregions and 
>>> split packages.
>>> How are split-packages supposed to be treated by the resolver in case an 
>>> imported-package from bundle a in region A can be resolved from bundle b 
>>> (in region A) and bundle c (in global region).
>>> Is there any special rules applied here for split-packages across regions?
>>> 
>>> Thanks in advance,
>>> Konrad
> 
> -- 
> Carsten Ziegeler
> Adobe
> [email protected]
> 

Reply via email to