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
