Don't worry, I never read it either but was forced to write it up ... :-)
Kind regards,
Peter Kriens
On 11 okt 2010, at 14:48, Alexander Shutyaev wrote:
> 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
