Eric pointed out correctly, that there was tight connection between SLING API and Scripting core, as the package import range on scripting core (bundle version 2.4.8) is quite narrow for the package org.apache.sling.api.scripting:
org.apache.sling.api.scripting; version="[2.5, 2.6)" This is caused by the class LazyBindings being a ConsumerType ( https://github.com/apache/sling-org-apache-sling-api/blob/bdbd1768969917d0e2436d5b008fff80aaa729dc/src/main/java/org/apache/sling/api/scripting/LazyBindings.java#L56) and the scripting core inheriting from it (in ProtectedBindings). My latest extension to it (SLING-12062) then caused a bump of the exported version, thus breaking the existing imports. Of course I could do a release of the Scripting Core as well and make sure that it works with the package version as well, but I wonder if this is the right thing to do. Should the Sling API export ConsumerType interfaces and classes at all, which can cause this type of problems, or should we try to avoid them? This is a more general question; and in case that we want to avoid those, the question is still how we want to move forward with this specific instance of it. My personal opinion is * to avoid @ConsumerType exports in the Sling API in general and * move the ProtectedBindings class, which inherits from the LazyBindings over to the API that would allow us to have a wider import range on the scripting.core side. WDYT? Jörg -- https://cqdump.joerghoh.de
