Seems like I did reinvent the wheel! :) Thanks a lot for showing me the right way. The specification is big enough and it just so happened I never read Attributes Matching section before...
2010/10/11 Peter Kriens <[email protected]> > It sounds to me like one of those things that look really tempting to have > when you only focus on the functionality but create an amazing amount of > complexity in other places and use cases because they affect the spec in so > many places. In the examples you give it seems you can easily handle this > with different bundle symbolic names? They are really different bundles and > this invariant is fairly important in OSGi ... > > Notice that if you use Import-Package instead of Require-Bundle you do not > have to encode the different names in your bundle. Just use attributes on > the package if you want to be sure to get a specific variant. > > normal.jar > Export-Package: com.example.book > > normal+hibernate variation > Export-Package: com.example.book; enriched=hibernate > > normal-deplete variation > Export-Package: com.example.book; depleter=xyz; mandatory:=depleter > > normal+hibernate-deplete variation > Export-Package: com.example.book; enriched=hibernate;depleter=xyz; > mandatory:=depleter > > Usage: > // matches > Import-Package: com.example.book // normal + > hibernate > Import-Package: com.example.book; enriched=hibernate // only > hibernate > Import-Package: com.example.book; depleter=xyz // depleted > versions > > Hope this helps, kind regards, > > Peter Kriens > > > > > On 8 okt 2010, at 16:04, Alexander Shutyaev wrote: > > > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
