Added merging prerelease sdk and addons with regular one

[michalwedzik]

In this PR, I added support for merging prerelease SDKs and add-ons with their regular counterparts.

Description

For now, this functionality is available only through AemAggregator when the following fields are provided:

prereleaseSdkId
prereleaseAddOnIds

If these fields are left empty, the behavior remains unchanged. When they are set, the features from the prerelease SDK and/or add-ons are merged with the corresponding regular SDK and add-ons.

Related Issue

#362

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[michalwedzik]

I'm not sure what is expected for the empty feature.

[rombert]

I think checking for 'empty' features is not the right heuristic. I suggest that you take a look at some of the add-on SDK APIs published on Maven Central and either test directly against them or add simplifed copies to git. AFAICT there are two main scenarios:

• a prerelease sdk add-on API that repeats the 'main' add-on API and includes some extra exports/bundles, like https://repo1.maven.org/maven2/com/adobe/aem/aem-dox-prerelease-sdk-api/2026.3.1/aem-dox-prerelease-sdk-api-2026.3.1-aem-dox-sdk.slingosgifeature
• a prerelase sdk add-on API that is additive (technically speaking empty ones like https://repo1.maven.org/maven2/com/adobe/aem/aem-prerelease-sdk-api/2026.6.26635.20260611T122956Z-260500/ are additive :-) )

In both scenarios feature aggregation should work and we probably need to either define a merge handler or conflict policies. If you did not try out the two cases outlined above please do and let's see how this plays out.

[michalwedzik]

I implemented it the way we discussed. I added ApiRegionsMergeHandler to handle merging apiRegions, and AssemblyBasedFeatureConflictResolver.java to choose the correct version when conflicts occur.

I think I've covered all the scenarios.

[rombert]

I think this should assert that both exports are kept, right?

[michalwedzik]

No, I adopted the strategy that whenever a specific key exists, I replace its value with the prerelease version.

I want to avoid writing a complex merging strategy for the content:

 "api-regions:JSON|false":[
    {
      "name":"global",
      "exports":[
        {
          "name":"ch.qos.logback.classic",
          "deprecated":{
            "msg":"This internal logback API is not supported by AEM as a Cloud Service.",
            "since":"2022-01-27",
            "for-removal":"2025-08-31"
          }
        }
      ]
    },
    {
      "name":"com.adobe.aem.deprecated",
      "exports":[
        {
          "name":"org.apache.abdera.ext.opensearch",
          "deprecated":{
            "msg":"Legacy AEM 6.x API.",
            "since":"2019-04-08",
            "for-removal":"2025-08-31"
          }
        }
      ]
    }
  ],

Otherwise, I'll have to implement a strategy for handling duplicates.

[michalwedzik]

I afraid of to have structure like:

"api-regions:JSON|false":[
    {
      "name":"global",
      "exports":[
        {
          "name":"ch.qos.logback.classic",
          "deprecated":{
            "msg":"This internal logback API is not supported by AEM as a Cloud Service.",
            "since":"2022-01-27",
            "for-removal":"2025-08-31"
          }
        }, 
         {
          "name":"ch.qos.logback.classic",
          "deprecated":{
            "msg":",
            "since":"2022-01-28",
            "for-removal":"2025-08-31"
          }
      ]
    }
  
  ],