OSGi “visibility:=reexport” directive

After removing some “visibility:=reexport” directives in my plugins, my workspace crashed as hell. The Eclipse problems view and the error messages where also quite confusing and misleading. Anyhow, I managed to fix all issues after investing some hours of work. I decided to import all needed dependencies in the MANIFEST.MF directly from now on. Furthermore, I decided to not use the “visibility:=reexport” directive anymore.

How are your experiences?


About Philip Wenig

Founder of OpenChrom
This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to OSGi “visibility:=reexport” directive

  1. I personally remove this “reexport” thing to have clear dependencies in our ~170 projects, but sometimes it is useful. There can’t be general answer to the “never use tool XYZ”, it depends on your needs.

  2. I don’t use the reexport directive any more. This way I achieve explicit dependencies having always correct version ranges. Removing this directive took me one day for 100+ bundles. But now I feel much more safe.

  3. holmes70 says:

    Bundles usually contain public code (API) and internal code. If the API of a bundle exposes types from required bundles I tend to reexport those required bundles to relief my API consumers from finding and requiring those extra dependencies. If the extra dependencies are only needed to make my own internal code happy I usually don’t reexport them. A cleaner way would be to completely separate my API from the implementation code, then I could say API bundles reexport everything and implementation bundles reexport nothing, but that would duplicate the number of my bundles and with Eclipse PDE insisting on one workspace project per OSGi bundle that always seemed like overkill to me.

    Of course, whenever you reexport something that you can’t control you must trust that it plays nicely according to the rules of semantic versioning or you risk that your own API gets broken, i.e., you not only use/offer their API, you also take over their version management. But this is more a question of whether you use such 3rd party API in your own API or not and not a question of whether to reexport it or not.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s