support OSGi manifest entries

[GoogleCodeExporter]

Please support OSGi manifest entries. This will enable use of the library 
within OSGi runtimes 
without requiring post-processing by downloaders.

Original issue reported on code.google.com by steven.marcus on 8 May 2008 at 11:50

[GoogleCodeExporter]

I have no idea what this means :) but I'm happy to accept a patch for this, as 
it
sounds perfectly harmless.

Original comment by kevin...@gmail.com on 27 May 2008 at 7:11

[GoogleCodeExporter]

Attached is a MANIFEST.MF file that has the minimal information required by 
OSGi.
The Bundle-Version attribute will need to be updated.

Also, see

http://www.springsource.com/repository/app/bundle/version/detail?name=com.spring
source.com.google.common.collect&version=0.5.0.alpha&searchType=bundlesByName&se
archQuery=google

for a repackaged jar that is OSGi ready.

Would be great if future versions in the maven repo were OSGi-ready.

Thanks!

Original comment by steven.marcus on 28 May 2008 at 3:03

Attachments:

• MANIFEST.MF

[GoogleCodeExporter]

OSGi makes me happy.

Original comment by lukewpat...@gmail.com on 20 Nov 2008 at 5:52

[GoogleCodeExporter]

If you want to add OSGi metadata during the build you can use the attached patch
which uses the Bnd Tool to generate the appropriate headers. FYI, I took the 
latest
version of Bnd from 
http://www.aqute.biz/repo/biz/aQute/bnd/0.0.305/bnd-0.0.305.jar

This patch also adds a new property "api.version" which you can use to version 
the
API separately from the jar version (for example, you may have a 1.0.2 bugfix 
jar
that still honors the 1.0 API).

There are 2 lines in the patch that use Bnd macros, which probably need 
explaining:

  <property name="Bundle-Version"
value="${replace;${version};^[^0-9];${api.version}.$0}"/>

This uses the Bnd replace macro (http://www.aqute.biz/Code/Bnd#macros) to 
prefix the
project version with the API version, but _only_ when the project version 
doesn't
start with a number. For example:

 version=snapshot  api.version=1  ...  Bundle-Version=1.0.0.snapshot
 version=1.0.2     api.version=1  ...  Bundle-Version=1.0.2
 version=snapshot  api.version=2  ...  Bundle-Version=2.0.0.snapshot

The other Bnd macro is used to automatically compute the valid import version 
range:

  <property name="api.range"
value=""[${api.version},${version;+;${api.version}})""/>

This uses the Bnd version macro to create a range from the current API version, 
up to
but not including the next major API version (where API breakage is most likely 
to
occur). For example:

 api.version=1     ...  api.range="[1,2)"
 api.version=2.0.1 ...  api.range="[2.0.1,3)"

All google-collections packages (except com.google.common.base.internal) are 
then
exported with the API version, and imported using the acceptable API range. 
This is
good OSGi practice, and helps developers when they want to update to new 
versions.

The other header settings are taken from the Ant project and the project 
website. 

PS. if you want to keep using the jar task and instead add the generated 
manifest
separately then take a look at the Guice common.xml file, which does exactly 
this.

HTH, if you have any questions let me know - I've also attached an OSGi manifest
generated using this patch, in case you decide to add these headers manually :)

Original comment by mccu...@gmail.com on 10 Dec 2008 at 10:44

Attachments:

• google-collections-issue-64-bnd.txt
• bnd-0.0.305.jar
• MANIFEST.MF

[GoogleCodeExporter]

This is actually not a defect but I would happy if OSGi bundle manifest would be
embedded automatically during build.

Here is home page of bnd tool that was mentioned above by mcculls:
http://www.aqute.biz/Code/Bnd

Original comment by PetrG...@gmail.com on 11 Feb 2009 at 8:53

[GoogleCodeExporter]

Any chance of this patch making 1.0 final?

Original comment by mpilqu...@gmail.com on 18 Jul 2009 at 4:01

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:00

• Added labels: Type-Task

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved