On 3/16/10 10:51, lukewpatterson wrote:
Richard S. Hall wrote:The two can be used to entirely the same thing (i.e., convert a JAR file to a bundle): * For wrapping, you simply add OSGi metadata to your normally generated JAR file manifest (i.e., you just have one JAR file). * For embedding, you create a container JAR file with OSGi metadata in its manifest and add the existing JAR file you want to embed into the container JAR file and its its location to the Bundle-ClassPath (i.e., you have two JAR files, one containing the other). The assumption here is you might not be able to modify an existing JAR file so you embed it rather than wrap it to convert it to a bundle. However, embedding provides a use case that wrapping cannot, which is having your own private copy. In some cases, you don't want to convert a JAR file into a bundle, you just want to use it inside your bundle. In that case you embed it, add it to your Bundle-ClassPath and don't expose it via Export-Package or whatnot, then it is your bundle's own private library.Thanks Richard. What you've written makes sense. With that new knowledge, let me throw out a couple statements that seem correct, and please let me know if I'm wrong: * an embedded jar doesn't "wrap", it is "wrapped" by the "wrapping" (enclosing and possibly exposing) bundle
Yes, I think that is correct. It is embedded into a wrapping bundle.
* a wrapper bundle may or may not contain embedded jars
This is not necessarily true, but in the simplest case it is true. I could decide as part of my converting a normal JAR file to a bundle that I want to embed some other dependent library. This would be ignored when the bundle JAR file was placed on the class path and would thus require the user to put the needed library on the class path, but when used in as a bundle, the dependent library would be resolved from the embedded copy. However, I think this is an edge case.
I don't think you should place too much importance on the terms "embed" versus "wrap", they are just descriptive terms, not really technical ones.
-> richard --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
