> Note that Conditional-Package does NOT create source redundancy. Any bug that > creeps up and fixed is automatically fixed next time the bundle is build (and > tested). Really, the problem you sketch is non-existent. On the contrary, in > my experience it increases robustness. Instead of finding the new util jar in > runtime you test the bundle using the Conditional-Package with the exact > version you'll deploy.
One of the touted benefits of OSGi and version ranges etc is that you can pick up new things as they come available and do not have to ship monolithic wads. Promoting the "put your prereqs in your bundle" approach seems counter to that model. What do you see as the difference? As for the problem being non-existent... I accept that "in your experience" it has not been a problem. However, I've seen people use other approaches because they see it as a problem. Acceptability is in the eye of the beholder. I agree that the "copy the binaries" approach works perfectly fine in many situations. As does the fine grained bundle approach and, heaven forbid, the common/util bundle approach. > You point out a subtle difference between a util and an interoperability > standard. Utility classes with Conditional Package must not appear in the > public API of the bundle because each bundle has its own binary copy. A util > is supposed to do some repetitive work, not provide important abstractions. > Those are services. You are making a particular assumption about the definition of "utility class". Is the expectation that util classes never appear in API? It's not clear that everyone on this thread is working with that assumption (might just be me who is/was not). Perhaps the definition should be flipped around. util classes are, defintion, the things that a bundle uses that do not appear in their api and the bundle author did not write? That seems useful but pretty narrow. As for abstraction and service-ness, I know where you are going but you skipped over a whole mess of important classes like String, Path, <and more complex datatypes> ... that provide important abstractions/function (some would even say "utility") but few would argue should be services. These may or may not appear on the API of various bundles. If they do then we have to be careful about maintaining the class space and we still have the open question about how to bundle them. For example, if every Eclipse bundle that used Path had its own copy we would have hundreds of copies on disk and many of these would be in memory (if the bundle does not import). The class is say about 20K. Thats just one example but it already points to potentially megabytes of wasted memory. In the end a lot depends on the numbers. How many util classes? How big are they? How many consumers? How many used in API (thus imported)? How often to they change? How many users are in your control? Jeff _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
