I am strongly in favor of letting bnd generate the Import-Package headers (incl. version ranges) and to not tweak those manually. Manually adjusting the process is IMHO very error-prone. Konrad
> On 26 May 2016, at 18:13, Julian Sedding <jsedd...@gmail.com> wrote: > > 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 >>>
