Use bnd-resolver-maven-plugin to check runtime compatibility with multiple AEM versions

[kwin]

As there were recently some issues with compatibility in different versions of AEM (e.g. #2298) I suggest to use https://github.com/bndtools/bnd/tree/master/maven/bnd-resolver-maven-plugin to check the bundle constraints against multiple OSGi containers (lowest supported AEM version and newest supported AEM version).

A similar check has been implemented recently in apache/jackrabbit-filevault@b8e952d.

That way the build will fail if the acs-aem-commons bundles cannot be resolved in one of those containers. It still needs to be checked if the uber-jars can be used for that check....

[kwin]

At least the relevant provide-capability headers seem to be missing from https://repo1.maven.org/maven2/com/adobe/aem/aem-sdk-api/

[joerghoh]

To address the same problem I would rather try to build against multiple versions of the uber.jar (6.4,6.5, AEMaaCS) with Travis.
My impression is that right now we cannot rely solely on OSGI metadata.

[kwin]

We have to distinguish between compile time resolution failure and run time resolution failure. In some cases although at compile time everything is correct a bundle still cannot be resolved in certain AEM versions at run time. Therefore I would really like to introduce this additional OSGi resolver check.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kwin]

I opened https://issues.apache.org/jira/browse/SLING-9883 to include the necessary manifest headers in future AEM API jars.