I think I found it:

"Exports declared earlier in the api-regions array also apply to later elements 
in the array, so the platform region also contains all exports declared for the 
global region.”

(From 
https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions/blob/master/docs/api-regions.md#visibility-of-java-api).

This indeed would prevent multiple isolated regions.
I am wondering though why these semantics are necessary, as for global and one 
custom region the exports from the global one are implicitly visible to 
everyone.

So just removing this limitation/feature seems reasonable to me and require all 
exports to be explicitly listed per region.
WDYT?
Konrad


> On 28. Oct 2024, at 19:57, Konrad Windszus <[email protected]> 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
> 

Reply via email to