Hi,
I had a lengthy offline discussion with Carsten regarding this topic, and I
did not really find a good solution, without the need to deal with this
tight coupling.
Also in order not to overly complicate things I decided to undo SLING-12062
and then close the ticket as incomplete. The small ben
Are we sure that this is the right solution?
With the proposed solution, scripting core needs to be changed regardless.
But more important, now every bundle that uses LazyBindings will get a
narrow package range not just scripting.core.
Or in other words, scripting.core will continue to have a na
Hi Julian,
regarding the "LazyBindings.putOnly" method, the motivation was a mostly
about performance, as I found a number of occurrences, where the put method
actually resolved the supplier, but the return value of put() was not used
at all.
Also I want to avoid any change on the semantics of pu
Hi,
The following example table lists the ranges being generated for the exported
version 1.1.0 depending on the usage and annotations:
Annotation on class/interface | Version | Implemented/Extended | Import-Package
Version Range | Versioning Policy
==
Hi Jörg
In general, I agree that we could, and maybe should, evaluate which
types in the Sling API should be @ProviderType instead of
@ConsumerType. My assumption would be that most types should be
@ProviderType. I don't know what sort of versioning change adding the
@ProviderType annotation cause
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 cause
