Have you looked at the forthcoming generic requirements and capabilities feature in http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft2.pdf ? --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Alexander Shutyaev <[email protected]> To: [email protected] Date: 2010/10/08 10:15 Subject: [osgi-dev] bundle version branching mechanism Sent by: [email protected] Good {time_of_day} to all! I have come upon an idea of bundle version branching mechanism. The goal is to allow the developers to create customized versions of bundles based on some parameters (as in gentoo's USE variable). There are two type of these parameters - 'enrichers' and 'depleters'. _____Enrichers_____ An 'enricher' parameter indicates that some extra functionality has been added to the original bundle while PRESERVING FULL COMPATIBILITY. For example, let's say we have some bundle that utilizes some book-store model. It would be logical to assume that this bundle has some 'entity' objects like Book, Author and so on. Now we have two developers using our bundle. One of them want to use it to store information in database via Hibernate while the other wants to exchange data in some client-server application. We could add Hibernate annotations to our entities to make developer#1 happy, but that would mean Hibernate dependencies for our bundle and would require developer#2 to add some unnecessary bundles to his target environment. Now consider the following. We supply two bundles: 'org.foo.bookmodel-1.0.jar" and 'org.foo.bookmodel-1.0+hibernate.jar" where the first one contains pure entities and the second contains the same entities with hibernate annotations added. The second bundle's MANIFEST.MF file would contain something like: Bundle-Enrichers: hibernate And developer#1 would put something like: Require-Bundle: org.foo.bookmodel;bundle-version=1.0;required-enrichers=hibernate in his bundle's MANIFEST.MF file. When resolving dependencies, OSGi container looks for the bundle that declares a SUPERSET (maybe PROPER) of all the required enrichers. _____Depleters_____ A 'depleter' parameter indicates that some functionality has been removed from the original bundle. For example, In our 'bookmodel' bundle we could have an ISBN class that provides some ISBN-related functionality like 'getCountryCode()' etc. But it is logical to assume that many developers will use ISBN just as a string. So we could have a version of our bundle that will contain a stripped version of ISBN class with only 'toString()' method. The bundle would be something like 'org.foo.bookmodel-1.0-plain_isbn.jar'. It's MANIFEST.MF file would contain: Bundle-Depleters: plain_isbn And developers would put something like: Require-Bundle: org.foo.bookmodel;bundle-version=1.0;accepted-depleters=plain_isbn in their bundles' MANIFEST.MF files. When resolving dependencies, OSGi container looks for the bundle that declares a SUBSET (maybe PROPER) of all the accepted depleters . Of course we can combine it with enrichers and have something like 'org.foo.bookmodel-1.0+hibernate-plain_isbn'. So this is my idea. Maybe I've reinvented the wheel =) If so, please tell me how can I achieve my goals with OSGi. If not, then tell me what you think about this idea. And if the majority finds it interesting, then tell me what are my steps to bring this idea into the specification... Thank you for your attention! _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
