Bundlor
  1. Bundlor
  2. BNDLR-196

Make bundlor match the lowest compatible version instead of the one available

    Details

    • Type: Story Story
    • Status: To Do To Do
    • Priority: Major Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Labels:
      None

      Description

      The biggest issue I have with bundlor and the bnd tool respectively is that it doesn't take into account which version is suitable for me. As a tool it is quiet dump, it just picks the version numbers being available in my dependency tree instead of abstacting (if possible) and taking the lowest fitting version. This is usually not a problem within my very own application, if I have total control over every bundle, but as soon as one starts to develop libraries used by others (like the spring repository for 3rd party libraries and springs core components relying on these 3rd party libraries) this becomes crucial, because others might not use or are even not able to use the latest versions the library creator is using. Unfortunately as soon as I rely on the latest version (although it is not necessary), I can no longer use the library because of unsatisfied dependencies. (For instance in Spring 2.5.6 you're relying on commons-fileupload, which defines a dependency on the 2.5 version of the Servlet API, which is way too high)

      In order to be able to do this, one need to have a repository of all (older) versions of the paritcular dependency (with the correct version information of each bundle and it's packages) and compare the compatibility of these libraries(on the class API level of the exported packages) to my needs. This can be accomplished by code analysis of the public interfaces with respect to the binary compatibility specification of the Java Language Specification ([http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html). Also a common understanding of how to version a bundle correctly is required (see sample approaches from Eclipse below). Of course, this is not guaranteed to succeed, because semantic changes can't always be picked up, but here a human interaction at release time can make up for this. The tool should propose the next version number of a package and the developer releasing it should be able to adjust it on a as needed basis.

      I understand that this is a challenging task, but in order to built components reusable as libraries on a mix and match basis (like in productlines, what the company I am working for is doing), this is the next step to take and can make the difference for OSGi as the componentization technology.

      Here are a few links relevant to that matter (as a starter):
      http://wiki.eclipse.org/Evolving_Java-based_APIs
      http://wiki.eclipse.org/Evolving_Java-based_APIs_2
      http://wiki.eclipse.org/Evolving_Java-based_APIs_3
      http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
      http://wiki.eclipse.org/Version_Numbering

        Activity

        No changes have yet been made on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mirko Jahn
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: