[slf4j-dev] [OSGi] Manifests

[John E. Conlon]

John E. Conlon wrote:
> Ceki Gülcü wrote:
>   
>> Comments inline.
>>
>> At 01:32 AM 1/31/2007, John E. Conlon wrote:
>>     
>>> Peter Kriens' Bnd tool for OSGi bundle creation is a very handy tool for
>>> creating and verifying bundles.
>>> See:  http://www.aqute.biz/Code/Bnd
>>>
>>> I used it to verify our maven created jars and it reported a couple of
>>> errors with our OSGi metadata.  Here is an example of the output from
>>> the tool:
>>>       
>> [snip]
>>
>>     
>>> 4 : Invalid value for Bundle-Version, 1.3-SNAPSHOT does not match
>>> [0-9]+(\.[0-9]+(\.[0-9]+(\.[0-9A-Za-z_-]+)?)?)?
>>>       
>> Reading the above message, I would say that "1.3-SNAPSHOT" is not a 
>> legal version number but "1.3.0-SNAPSHOT" is. So we can perhaps retain
>>     
> Actually "1.3.0-SNAPSHOT" is not legal but "1.3.0.-SNAPSHOT" is.
>   
>>     <Bundle-Version>${project.version}</Bundle-Version>
>>     
> I like keeping it all in one place as you have above.
>   
>> instead of
>>
>>     <Bundle-Version>1.3.0.SNAPSHOT</Bundle-Version>
>>     
> Right, rather not have the above.
>   
>> in pom.xml, subject to the condition that ${project.version} equals 
>> "1.3.0-SNAPSHOT" or 1.3.0 or 1.3 but not 1.3-SNAPSHOT.
>>     
> Again we would need a third period before the dash or letters. as in 
> "1.3.0.-SNAPSHOT"
>   
>>> Would it cause anyone any pain if we removed the Bundle-Classpath from
>>> our manifests?
>>>       
>> The current manifest entries mimic the entires found in Spring-OSGi 
>> (see [1]). I don't mind if they are removed although I wonder why they 
>> are present in spring-osgi.
>>     
> Some developers are using the Eclipse to build the manifests and Maven 
> for project layout.  When this is done they are have to use the 
> Bundle-Classpath with as a hack to get the project  recognized by 
> Eclipse.  
>
> Generating the metadata by hand or with assistance from Eclipse within a 
> Maven project often runs into problems.
> The preferred practice is to use the bnd tool which is also available as 
> a maven plugin.  The plugin version will automatically generate much of 
> the manifest from the pom.  For example:
> <Bundle-Version> is assumed to be "${pom.version}" with '-'
>      character separator of the qualifier replaced with a '.' character.
>
> I have not used the plugin with 'Split Packages' that need 
> Require-Bundle for package aggregation (like we are doing in slf4j), but 
> tomorrow I will experiment with it to see how it handles these.
>   
Peter has no plans to support Require-Bundle in the plugin, so I guess 
we must manually edit the plugin or create a new one ourselves.  Just so 
you know - although supported by the spec Require-Bundle is not 
considered 'best practice' for specifying dependencies between packages 
in bundles. 

For some of the issues and potential problems see
1. The OSGi specificati blog entry of archive -
http://www.osgi.org/blog/2006_01_01_archive.html

2. Or this background -
http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html

3. The r4 core spec Section 3.13 'Requiring Bundles'.  Goto
http://osgi.org/osgi_technology/download_specs.asp?section=2
to request the spec.

cheers,
John
> BTW - Richard Hall only commited the Require-Bundle functionality to 
> Felix today! 
>
>