Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Status of "uses" directive in Equinox and Orbit bundles

Hi, Tom,

I'll find a way to get my set-up to you.  Thanks!

On the subject of re-exports:  I thought Eclipse's recommendation was
always to re-export dependencies whose types comprise part of a bundle's
API (as in "uses").  Say I have:

   Bundle A
       - package a
         - class X extends b.T
            - public b.U getU()
       - MANIFEST.MF
          - Export-Package: a
          - Require-Bundle: B

   Bundle B
       - package b
         - class T
         - interface U
       - MANIFEST.MF
          - Export-Package: b

I thought the general recommendation was that A should re-export B to
ensure that users of the "a" package A don't have to specify a version
tolerance on A if they only use the "a" package via "b."  Otherwise, if
they independently specify a dependency on A (or "a"), then they have to
keep the version tolerance in sync with B's dependency on A (or "a").
Moreover, when B later adds a dependency to bundle C with package "c" and
exposes types from "c" in its API, then users of B will have to add their
own dependencies on C (or "c") even if they don't know that they are using
B's APIs that use "c" (perhaps via reflection?).

Maybe much of this thinking is pre-OSGi/Equinox and needs to be updated?  I
know that on the project I work on, the rule that a bundle whose API is
surfaced in a dependent's API must be re-exported by that dependent is
applied absolutely.



Christian W. Damus
Component Lead, Eclipse OCL and EMF MQ/MT/VF
IBM Rational Sofware

             Thomas Watson                                                 
             com>                                                       To 
             Sent by:                  Orbit Developer discussion          
             orbit-dev-bounces         <orbit-dev@xxxxxxxxxxx>             
             01/04/2008 05:18          Re: [orbit-dev] Status of "uses"    
             PM                        directive in Equinox      and       
                                       Orbit   bundles                     
             Please respond to                                             
              Orbit Developer                                              

> Thanks, Tom,
> The product in which this problem came up is reasonably large (> 1000
> bundles).  Moreover, there are more than a dozen bundles within Batik
> all "use" each other.  It's a tangled web.  :-)   Perhaps, then, I shall
> try to re-introduce the "uses" in my bundles and beg you for help if I
> into difficulties.

OK, Please let me know if I can get access to your setup once you have
something available.  I would like to have a look to make sure the
has a relatively large and complex number of solution sets which for which
the resolver must select an answer from.  Unfortunately we are dealing
with an NP-Complete problem for which some situations will be solved very
quickly while others can take an exponential amount of time to solve.

> I have another question, not quite related.  I have discovered, I think,
> that whereas I can re-export API of a bundle dependency using the
> "visibility=reexport" directive in a Require-Bundle header, it is not
> possible to Export-Package a package that was Import-Packaged in order to
> re-export it (PDE flags it as an erroneous attempt to export a package
> defined in the bundle).  Is there a way to re-export packages obtained
> Import-Package?

No, you cannot reexport packages you get from Import-Package and I really
not like the visibility=reexport approach either.  To me this is just a way

to make our clients very lazy in their constraint definitions.  Just
someone requires you does not always mean that they will need access to
bundle you require.  The visibility=reexport option only makes the
transitive closure of your dependency graph that much more complex.  It
becomes much more difficult to look at a bundle's manifest and see where it

gets its external classes from.

OSGi does allow you to "reexport" a package from one of your required
though.  For example, suppose bundle A required bundle B and bundle B
the package along with a whole bunch of other b.* packages.  In
A would like reexport the package to other bundles that require
bundle A but not all the other b.* packages.  In this case you would use
following in bundle A

Bundle-Symbolic-Name: A
Require-Bundle: B

This is perfectly ok in OSGi, but I expect PDE will flag a warning/error
you are exporting a package not included in your bundle.  You can safely
ignore this error/warning.  Personally I do not really mind the error
because I really do not think reexporting packages or required bundles is a

good thing :)  To me all clients should clearly define their requirements
additional requirements should not be induced on a client through a
on a bundle (i.e. Require-Bundle).

> Thanks for your help!
> Christian
> Christian W. Damus
> Component Lead, Eclipse OCL and EMF MQ/MT/VF
> IBM Rational Sofware
> _______________________________________________
orbit-dev mailing list

Back to the top