Unable to install app on aem 6.5.9

[bartoszWesolowski]

Describe the bug
Installing the all package on AEM 6.5.9 (with all required dependencies present) fails due to missing cloud dependencies:

com.adobe.cq.dam.download.api,version=[3.4,4) -- Cannot be resolved but is not required
com.adobe.cq.dam.download.spi,version=[1.1,2) -- Cannot be resolved but is not required

I followed instructions from documentation and added dependency for

<dependency>
    <groupId>com.adobe.aem.commons</groupId>
    <artifactId>assetshare.all</artifactId>
    <version>2.3.4</version>
    <type>zip</type>
</dependency>

Logs when I try to activate the bundle

02.09.2022 13:32:27.758 *ERROR* [qtp1818270852-2448] org.apache.felix.http.jetty Bundles: Cannot start (org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))])
org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))]

Environment

• AEM Version: 6.5.9
• Asset Share Commons Version: 2.3.4
• Author, Publish or both: both

To Reproduce
Steps to reproduce the behavior:

1. Install all package on AEM 6.5.9 (or probably any on-prem AEM)

Expected behavior
Application works (bundle active)

[davidjgonzalez]

Hi! This is expected for 6.5 since the AEM CS download framework is not available on 6.5. This is why these imports are optional.

That said, ASC should fall back on 6.5 to an internal implementation that supports downaloads being orchestrated in the AEM JVM. Please let us know if the download aren't working on 6.5 -- vs just having an optional dependency being unsatisfied (again, it's optional for a reason)

[bartoszWesolowski]

Hi @davidjgonzalez

You are right - missing imports are optional and they do not cause the problem with this bundle. As far as I understand bundle was failing to start because of missing dependency (based on the error log)

02.09.2022 13:32:27.758 *ERROR* [qtp1818270852-2448] org.apache.felix.http.jetty Bundles: Cannot start (org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))])
org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))]

and mostly this part of the log (osgi.contract=JavaActivation)(version=1.2.0).

I checked the documentation and found out that on my AEM bundle exporting javax.activation package had version 1.1.1 and asset-share-commons bundle required version 1.2.0

I installed additional bundle locally and it resolved the issue:

<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.javax.activation</artifactId>
    <version>0.3.0</version>
</dependency>

I guess this still needs some fix in the app - I am not sure whether this should be included in the app package or maybe documentation needs to be extended.

[kwin]

This is a regression of #767. Using dependabot on OSGi dependencies is usually not helpful.

[davidjgonzalez]

@bartoszWesolowski This should be fixed in 2.4.0 (just released) - thanks to @kwin for spotting this.

I tested it on my 6.5.9 and everything resolves.

Please re-open if you see anything funny.