+1 to Bertrand's summary. That matches my understanding of how we're
dealing with 3rd party dependencies in Sling.

1. Keep the *required* version of a 3rd party library (an external API
we depend upon) as low as easily practical. I.e. normally we don't
work around bugs or missing new APIs in 3rd party libraries, but we
don't raise the required version of the dependency just because it is
available and thus artificially reducing the bundle's compatibility.

2. For tests or deployments (e.g. lauchpad), we aim to use the most
recent version of the 3rd party dependency. As that is outside of a
bundle's build, none of the Import-Package version ranges will be
affected.

This is a relatively simple way to create bundles with strongly
compatible Import-Package version ranges.

Regards
Julian

On Thu, May 26, 2016 at 2:46 PM, Konrad Windszus <konra...@gmx.de> wrote:
> Hi,
>> Am 26.05.2016 um 14:36 schrieb Bertrand Delacretaz <bdelacre...@apache.org>:
>>
>> Hi,
>>
>> On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus <konra...@gmx.de> wrote:
>>> ...there was quite a discussion going on in 
>>> https://issues.apache.org/jira/browse/SLING-5603 on how
>>> to deal with 3rd party dependencies in Sling....
>>
>> My opinion, and I think this is what we've been doing in Sling forever
>> even if we didn't explicitly document it, is that if a bundle B
>> depends on another *for its API* then the dependency should list the
>> lowest possible version.
> What do you mean by its API? In SLING-5603 we were talking about a dependency 
> in the API Provider (Validation Core), not the API bundle itself.
>
>>
>> This makes B easier to use in many contexts, as long as the right
>> version of the API, or a later one, is provided.
>>
>>> ...Another aspect of option a) is: With which version of the dependency you 
>>> want to run the IT....
>>
>> This is the "recommented implementation" aspect of the dependency,
>> which is a different concern.
>>
>> For this I suggest using the latest version of the implementation, or
>> at least the one that we recommend.
> If we don’t test with the minimum version we depend on (and which determines 
> the import-package version range) the risk for depending on an non-working 
> library version is IMHO much too high. Therefore I would recommend to test 
> with that minimum version. Testing the recommended or latest version does 
> give less confidence that the bundle B really works with the lower version of 
> the dependency.
>
>
>>
>> -Bertrand
>

Reply via email to