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
