Support multiple versions of Core Components deployed at the same time

[kwin]

Feature Request

For some edge cases it might be beneficial to deploy multiple versions of the Core Components at the same time. That is technically supported in AEMaaCS already via https://sling.apache.org/documentation/bundles/osgi-installer.html#multi-version-support-1, but the code is not ready for that yet:

OSGi services for which a single implementation is expected should be sorted by version number, i.e. the highest version number implementation should get bound. To achieve that the version must be converted into an integer and then set as service.ranking property (https://docs.osgi.org/specification/osgi.core/7.0.0/framework.service.html#framework.service.servicerankingorder). Service implementations which should get such a ranking are

• https://github.com/adobe/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/services/CaConfigReferenceProvider.java
• CA Configs like https://github.com/adobe/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/services/pdfviewer/PdfViewerCaConfig.java

The filter.xml of content packages must not be overlapping. In the best case the major version is also reflected in the package name (and not only in the package version), as then the visualization in the CRX Package Explorer is better.

[ky940819]

I think being able to support multiple versions of Core Components would be very beneficial because it would free the Core Components to make breaking api changes in major version releases, without breaking clients applications that depend on previous versions.

I'm not saying there should be breaking changes all the time, but with the current setup I don't see any way that the Core Components can evolve over the long term, you eventually build up so much legacy that the project ends up locked into decisions that may no longer be the best.

[vladbailescu]

What do you understand by "multiple versions of the Core Components":

1. Multiple versions of the bundle? What's the value of this as we have two other different options: make changes in a backwards compatible way (only add new classes/members and deprecate instead of removing) or version the models (and possibly get rid of interface + Impl and export the full model so that developers can extend/compose directly instead of delegation pattern).
2. Multiple versions of the bundle and content package(s)? In this case, how would the overlapping paths (resource types) be solved?

Note: I'm not pushing back, just trying to understand what problems we're trying to fix and figure out PROs/CONs for different approaches.

[kwin]

Let me try to elaborate:

What do you understand by "multiple versions of the Core Components":

I meant really multiple versions of the bundle and(!) content package(s). That would allow customers to use old (no longer supported) Core Component versions at their own risk in AEM Cloud (which always has the newest version of Core Components deployed).

That way you could easily restrict the amount of major versions per component (to 2) in each Maven module. Still making changes in a backward-compatible way would be best, but since this is not always possible sometimes major increases are mandatory. Currently each major increase leads to duplication of a lot of code. To make the code still manageable I would recommend to a) deprecate the old major version as soon as a new major version of a component is introduced b) to remove deprecated major versions of each component except for the last one

[vladbailescu]

@kwin, let me try to see if I got this right.

Let's say somebody is using Core Components 2.13.2, the current release, and referencing Image (v2) component:

sling:resourceSuperType="core/wcm/components/image/v2/image"

which, in turn, will use com.adobe.cq.wcm.core.components.internal.models.v2.ImageImpl. They want to lock in these dependency and embed 2.13.2 with their custom code/application.

Let's assume release 3.0.0 will include Image (v3) (core/wcm/components/image/v2/image and com.adobe.cq.wcm.core.components.internal.models.v3.ImageImpl). This will deprecate Image (v2) and remove Image (v1). Once that gets deployed to AEMaaCS, you would have an environment where:

1. core/wcm/components/image/v2/image will be covered by two packages (2.13.2 and 3.0.0).
2. com.adobe.cq.wcm.core.components.models.Image will be provided by two bundles (different package version for com.adobe.cq.wcm.core.components.models though, so that might be ok if the customer uses strict import range.
3. com.adobe.cq.wcm.core.components.internal.models.v2.ImageImpl will be provided by two bundles. Hard to say which will be preferred.

This seems very impractical (basically a Core Components Hell - https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell).

I would favour more that we keep old/deprecated versions in the releases and provide good tooling/guidance for migrating to newer versions.

[ky940819]

@kwin suggested in his original post that the package names contain the CC major version number. This is certainly something people do to resolve the issue, but it does make upgrade from 2->3 non-trivial. However, performing that upgrade isn't time-sensitive since the old version isn't disappearing tomorrow.

Exporting two versions of the same bundle can be done, but you are right that if they use the same resource types then it's not feasible. You would probably need to start versioning the resources types along the line of core/wcm/components/v3/image/v1/image which would be read as "version 1 of the image component in Core Components 3"

This would satisfy where @kwin said "The filter.xml of content packages must not be overlapping"

[tinatenatean]

The issue I run into with core components is when I install a new site instance using the latest version of the Archetype project to an environment that already has multiple site implementations. I will then often see an issue where, for example, the parsys height on the text component is 0 in Edit mode and the page won't autorefresh when an edit has been made. The components are there; they just don't work correctly unless I install the Archetype project on a fresh AEM instance without any other sites installed.