Use newest micro version of OSGi artifacts

Description

Please use the newest micro version of the individual OSGi artifacts both in AEMaaCS as well as AEM 6.5.12. They contain some nice fixes like fixed javadoc links and also some bugfixes without affecting the compatibility with the underlying OSGi spec chapter.

The following dependencies from have updates:

  1. org.osgi.resource 1.0.0 → 1.0.1

  2. org.osgi.service.metatype 1.4.0 → 1.4.1

  3. org.osgi.service.cm 1.6.0 → 1.6.1

  4. org.osgi.service.event 1.4.0 → 1.4.1

  5. org.osgi.service.http 1.2.1 → 1.2.2

  6. org.osgi.service.http.whiteboard 1.1.0 → 1.1.1

  7. org.osgi.util.converter 1.0.0 → 1.0.9 (contains implementation now as well)

  8. org.osgi.util.tracker 1.5.2 → 1.5.4

  9. org.osgi.dto 1.1.0 → 1.1.1

  10. org.osgi.service.url 1.0.0 → 1.0.1

  11. org.osgi.annotation.versioning 1.1.0 -> 1.1.2

  12. org.osgi.service.metatype.annotations 1.4.0 → 1.4.1

The one in AEMaaCS should be similar but they support OSGi Core R8 already.

Activity

Show:

Konrad Windszus March 11, 2022 at 7:55 PM

I created to get further insights.

Konrad Windszus March 10, 2022 at 12:25 PM

IIUC they are following semantic versioning, i.e. those dependencies should be backwards compatible. Also bnd generates the import-package version range only from the minor version (and disregards micro), so I fail to see any compatibility issues here, even if the versions exported from AEM have a lower micro version.

I don’t have an exact changelog either, unfortunately.

Stefan Seifert March 10, 2022 at 12:16 PM

currently, we derive all the versions we manage from the bundles that are actually deployed in the related AEM version:

some versions we take over from the aem-sdk-api POM (update-aem-deps:from-aem-sdk-api), most we derive from the package version that are exported from deployed bundles (update-aem-deps:bundle-package=…).

with this, we get the new versions if there is actually a new package version. we do not get updated versions if it contains only changes not affecting the package.

before applying the updated list of versions (some are already in place like org.osgi.resource 1.0.1) - how can we check that those updates of the versions are only cosmetic. i tried to get some changenotes or at least git diff between the version we actually have and the new version proposed, but failed to get those in an easy way from https://github.com/osgi/osgi - i do not see tags specific to the versions here, and am also confused about the meaning of the existing tags.

do you have more insight on this?

Details

Assignee

Reporter

Components

Priority

Created March 2, 2022 at 7:33 PM
Updated March 11, 2022 at 7:55 PM