felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Gravell <elstensoftw...@googlemail.com>
Subject Uses violations: cascading package version updates?
Date Wed, 25 Jul 2012 09:18:24 GMT
I have the following bundles:

bundle A {
  package a

  export-package:a
}

bundle B {
  package b.a
  package b.b
  package b.c
  package b.d
  package b.e

  import-package: a
  export-package:b.a;uses:=a,
    b.b;uses:=b.a,
    b.c;uses:=b.b,
    b.d;uses:=b.c,
    b.e;uses:=b.d
}

bundle C {
  package c

  import-package: b.e,
    a
}

Now, I update 'a' to a new version. C's required version of a is upped, but
not B's. My understanding is that this would cause a 'uses' clause
violation because C is exposed to the two versions of a direct from A (the
new one) and via B (the old one). And so it proves:

Chain 1:
  C [47.1]
    import: (&(osgi.wiring.package=a)(version>=1.1.0))
     |
    export: osgi.wiring.package=a
  A [9.1]

Chain 2:
  C [47.1]
    import: (&(osgi.wiring.package=b.e)(version>=1.0.0))
     |
    export: osgi.wiring.package=b.e; uses:=a
  B [33.0]
    import: (&(osgi.wiring.package=a)(version>=1.0.0))
     |
    export: osgi.wiring.package=a
  C [9.0]

Now I don't have any beef with this, it makes sense. There are two versions
of 'a' in the class space of C.

Oddly (in my eyes anyway) if I merely restart Felix then it all appears to
work. Surely if B was wired to version 1.0.0 of A it should remain so?
Anyway, that's not really my question...

My question is how to manage this.

The only way I've found to avoid the uses constraint violation is to
increase the version requirement to 'a' of every package that uses 'a',
then increase version requirements for all those users of 'a' and versions
of the packages that use those packages that use 'a' and so on. This
doesn't scale in any non-trivial case so I'm assuming I'm doing something
very wrong here.

Hoping for some insight...

Dan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message