i would like to import a package rather than require bundle in a manifest and have all bundles that require the former package inherit the imported package. I am assuming that it is possible to set visibility: reexport, but Eclipse does not complain if i had this option...
A:
I am not sure what your problem is. If you do not want to require a bundle, you have to import all packages you need. To generate this list you can use the maven-bundle-plugin (for maven projects). If you do not want to generate the concrete list of needed imports, than you can try
DynamicImport-Package: *
which should import the needed packages on demand.
K. Claszen
2010-08-16 09:49:50
Because DynamicImportPackages is the lazy wrong way. Theres a reason which require bundles exists because it gives the ability for the bundle supplier to state explicit whats needed and so on. Even members of the official OSGI group, will tell you that require bundles if the proper way. Nobody will ever tell you to use dynamicImpotPacakge.
mP
2010-08-16 13:57:19
I agree that it is not the elegant way and should be avoided but if it would have no relevance it would not be part of the specification! It is sometimes usefull for quick checks and absolutely needed if code includes Class.forName where you can not guess what class you have to deal with and therefore what packages you have to import. Nevertheless my answer does not seem to hit the question what I found difficult to understand. @mP Would be nice if you have an answer that fits.
K. Claszen
2010-08-16 14:42:56
Tassos Bassoukos
2010-08-16 22:47:05
That's right dynamic import is a hack and should be avoided.
mP
2010-08-17 06:46:00
A:
No, it's not possible to reexport a package. For that you will need to use a bundle, or a different class loading strategy.
Tassos Bassoukos
2010-08-16 22:42:30
A:
You can only reexport when requiring bundles.
Import-Package should be preferred over Require-Bundle or DynamicImport-Package. The former is only really necessary if you must deal with split packages whereas the latter was only intended to address situations where you didn't know the class name in advance (e.g., SPI-like situations), although it can also be used safely as an optional import-like facility. In general, you should be avoiding things that hide dependencies (e.g., broad dynamic imports) or obscure them (e.g., requiring bundles). The fact that Require-Bundle supports reexporting is a decision that should have never been made and there is no reasonable use case for this feature, all it does it further obscure dependencies and create a tangled mess.
Richard S. Hall
2010-08-17 01:29:32
What if your bundles are hierarchical. To use jee one needs javac.servlet which also needs amongst other things java. Let's pretend my problem parallels this sample. It's a bit silly to import everything when a hierarchy exists and can be used to automate dependencies. This just makes things overly verbose and nothing has gained. What's the point of making meAsk for bundle y if I use x if u already knownits an error to omit y? Giving a choice with 1 possible answer is nonsense.
mP
2010-08-17 06:52:04
Only ask me to implicitly declare what the container cannot guess. A container cannot guess what bunldes are required so it asks. It would be like declaring in java which methods a class inherits even if I don't override them but my superclass declares them. Why bother asking if u already know the answer...
mP
2010-08-17 06:54:37
I think you're getting confused about what OSGi requires you to declare. You *only* have to import the packages that you actually use in your bundle... just like Java source code requires `import` statements.Furthermore tools like Bnd can perform static analysis that tell you exactly which packages you are using, and it generates the Import-Package declaration for you. The Maven Bundle plugin uses Bnd internally to do the same thing.
Neil Bartlett
2010-08-21 22:23:28
A:
I'm apparently missing the "reply to comment" link, so forgive me that I'm replying to the question in the comments here...
Whether you are in a "hierarchy" or not doesn't really make a difference. First bundles are used in different contexts, so they won't always be used in a container that knows that they want. Second, a bundle still doesn't use everything available to it in a "hierarchy", so acting it does just leads to dependency fan out, since the real dependencies are hidden.
Richard S. Hall
2010-08-20 17:06:09
+1
A:
It's not possible and it's not necessary either. A bundle using Import-Package can simply obtain the package from the original bundle that exports it; there is no need to "route" the dependency through an intermediate bundle.
This is one of the biggest advantages of Import-Package: an importing bundle neither knows nor cares which other bundle(s) it's getting the packages from.
Neil Bartlett
2010-08-21 22:14:13