Addendum: I just read Olli's comment in the ticket. My requirement is that we keep the Import_package version ranges of bundles flexible in order not to require artificially high 3rd party dependency versions. How we achieve this is up for debate and ultimately a tooling issue (by default bnd generates the Import-Package version ranges based on the dependencies on the build class-path).
Regards Julian On Thu, May 26, 2016 at 6:06 PM, Julian Sedding <jsedd...@gmail.com> wrote: > +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 >>
