Original comment posted by kevinb9n on 2008-05-27 at 07:11 PM

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

Original comment posted by steven.marcus on 2008-05-28 at 03:03 AM

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.springsource.com.google.common.collect&version=0.5.0.alpha&searchType=bundlesByName&searchQuery=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 posted by lukewpatterson on 2008-11-20 at 05:52 PM

OSGi makes me happy.

Original comment posted by mcculls on 2008-12-10 at 10:44 AM

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 posted by PetrGlad on 2009-02-11 at 08:53 AM

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 posted by mpilquist on 2009-07-18 at 04:01 AM

Any chance of this patch making 1.0 final?

Original comment posted by kevinb9n on 2009-09-17 at 06:00 PM

(No comment entered for this change.)

Labels: Type-Task

Original comment posted by konigsberg on 2010-04-09 at 11:46 PM

So I'm thinking about building an update with with r03. Will that handle the problem for you?

Original comment posted by kevinb@google.com on 2010-07-30 at 03:56 AM

(No comment entered for this change.)

Labels: -Priority-Medium

Original comment posted by eclipseguru on 2011-01-20 at 10:53 AM

We are also looking at adding OSGi enabled JAR to Eclipse Orbit. However, we have a hard time to come up with a proper version scheme for the JAR itself as well as for individual packages.

Should we translate "r07" to "1.7.0" or to "0.0.7" or to "0.0.0.r07"?

We are also looking for advices on how to version the packages correctly. Any ideas?

Original comment posted by m.zdila on 2011-01-20 at 11:06 AM

Not sure, what is your versioning scheme, but OSGi uses major.minor.micro.qualifier

micro = bugfixes
minor = bugfixes and minor API changes, mostly backward compatibilie. Also deprecating old API
major = major API changes

Original comment posted by holger.hoffstaette on 2011-01-20 at 11:12 AM

Look at this thread:
http://groups.google.com/group/guava-discuss/browse_thread/thread/decb3a0600f1a669

Considering that there are already people out there using & building against 1.x.0 exports it would make most sense to retain that instead of moving to x.0.0 for no good reason.

Original comment posted by eclipseguru on 2011-01-20 at 11:12 AM

We are looking for advices on how to translate the Guava version "r07" into an OSGi version.

Original comment posted by eclipseguru on 2011-01-20 at 11:23 AM

Thanks a lot for the link to the tread. It seems that (recently) people tend to translate the simple numbers used by Guava into OSGi "major" version. That's perfectly fine given the statement "every release can introduce incompatibilities".

Original comment posted by tonit.com on 2011-01-26 at 09:37 PM

just wonder about the OSGi unfriendly-ness that interfaces (aka API) and implementation classes (e.g. Multimap and HashMultimap) are put into the same package. In OSGi class loading protection is achieved on package level. Its good practice to give API and implementation different package names. Did you consider this (not sure if i have read up all references and links in this issue).
Toni

Original comment posted by carl.hall on 2011-01-27 at 04:50 AM

I work on a project that has google-collections wrapped as a bundle and everything works great. Since it doesn't offer anything as services, there's no real worry about interfaces and impl being in different packages.

Original comment posted by kevinb@google.com on 2011-01-27 at 05:59 AM

No, we never considered anything like that. Never heard of this being a real concern.

Original comment posted by philippe.marschall on 2011-01-27 at 07:47 AM

I don't think it's an issue in this case since you want to expose the implementation as well.

See the org.osgi.util.tracker package for example exposes both interfaces and implementations.

http://www.osgi.org/javadoc/r4v42/org/osgi/util/tracker/package-frame.html

Original comment posted by konigsberg@google.com on 2011-01-27 at 03:25 PM

I'm gonna go ahead and close this -- see http://guava-osgi.googlecode.com and see if this basically solves your problem. Feel free to put issues with the implementation against that project if you prefer.

Status: Fixed

Original comment posted by carl.hall on 2011-01-27 at 03:36 PM

The guava-osgi-r07 jar looks like it will work great in OSGi. Thanks! Is there any chance of this showing up in a maven repo so I can include it in my build for my non-Eclipse environment?

Original comment posted by eric.jain on 2011-01-28 at 06:04 PM

I've been using http://guava-osgi.googlecode.com/, and have no complaints so far. Nevertheless, I might sleep a bit better if I could get the jar (with the few additional manifest entries that OSGi requires) from you directly.

Original comment posted by kevinb9n on 2011-01-28 at 09:23 PM

Sleep a bit better why?

Original comment posted by eric.jain on 2011-01-28 at 10:33 PM

I've relied on such arrangements to obtain jars with the required metadata (e.g. from ebr.springsource.com). But sooner or later updates get less frequent or stop altogether (e.g. check the version of Hibernate distributed on that site)...

Original comment posted by js.cedarsoft on 2011-03-05 at 04:58 PM

Come on guys. Why don't u simply add a MANIFEST.MF with valid entries? Just "copy" the sample from guava-osgi.
There shouldn't be any problem with it. If you prefer, one might add an additional build step that automatically generates the entries...

OSGi is becoming a main stream technology. And since the necessary changes are so small and without any negative impact when used without OSGi, I can't think of a reason why you don't add it.

guava-osgi is not a solution. This is just a work-around... I think we don't have to discuss the advantages of Maven Central here one more time...

Thanks

Original comment posted by kevinb@google.com on 2011-03-06 at 04:10 PM

Your update does a lot to express to us how disappointed "u" are with us, but does absolutely nothing to tell us what you think is actually wrong with the current solution. Which makes it less than actionable.

Original comment posted by ellis.m.a on 2011-03-06 at 10:23 PM

I'll try to explain some of the problems I see with the current situation.

Firstly, being able to use artifacts from the central maven repo is significantly more convenient more most users. It's simple (nay, trivial) to add a groupId/artifactId/version to existing Maven/Ivy/Sbt builds to resolve an artifact from maven central. This is as true for OSGI projects as any other. Of course, each of these build systems has a way to use custom repositories, but this can cause introduce new problems, as I'll explain...

Requiring users to use a third-party repository adds complexity. One particular case where this is problematic is in companies that use a repository manager (like Nexus), to keep copies of all the artifacts used by that company. Modifying repository manager configuration for every project that doesn't include OSGI metadata introduces unwanted work and risk. (The extra work includes keeping track of more repositories. The risk is that changing the configuration will affect other builds within the same company).

Even if we dismiss these problems, the guava-osgi project only provides a P2 repository, and not a maven repository. This makes using Guava in OSGI development outside the Eclipse ecosystem somewhat awkward, since neither Maven, Ivy or Sbt will resolve from P2 repositories without headaches (Tycho is a bloody migraine).

Furthermore, looking at the svn history of the guava-osgi repository, the jars in the repository change over time. Jars that change over time can cause headaches regarding reproducible builds. However, I think most people trust that jars in maven central won't change.

As a developer, it's frustrating if you can't simply checkout the latest version of a project, and build it in a form that can be used in your project. It makes it hard to build a snapshot version (say, if you really want a feature or bug fix that's not been released yet).

So, what can be done to address this? It would be useful if a committer (Kevin, maybe?) could say whether they're prepared to accept a fix for this issue, because as far as I can see, the patch previously submitted for this issue has not been acknowledged.

Was the patch perhaps ignored because committers are unwilling to check-in the BND jar? Or because they didn't want to modify the existing ant build? Or perhaps because the committers are unfamiliar with BND and didn't want to add it to the build?

One possible solution to fix this issue is to modify the pom.xml to run bnd (which would avoid checking in a jar and/or modifying the ant build). Would that be acceptable? Personally, I'm reluctant to submit a patch until I know why the previous patch was dismissed and/or whether it'd be considered.

Regards.

Original comment posted by konigsberg@google.com on 2011-03-07 at 04:05 PM

Come on guys. Why don't u simply add a MANIFEST.MF with valid entries? Just "copy" the sample from guava-osgi.
There shouldn't be any problem with it. If you prefer, one might add an additional build
step that automatically generates the entries...

That doesn't sound smart at all. If you want a version of Guava with osgi-friendly content, try guava-osgi.

I know nothing about Maven Central, and I've never heard before today that plug-in development is either with Maven or might as well not exist.

Original comment posted by konigsberg@google.com on 2011-03-07 at 04:07 PM

(No comment entered for this change.)

Owner: konigsb...@google.com
CC: mikael.barbero

Original comment posted by ellis.m.a on 2011-03-07 at 04:24 PM

I've never heard before today that plug-in development is
either with Maven or might as well not exist.

That sentence didn't make sense to me.

Please don't confuse Maven with Maven Central. Maven is just one build tool. Maven Central is a repository that can be used (and is used) by several build tools including Maven, Sbt and Ivy.

If you want a version of Guava with osgi-friendly content, try guava-osgi.

I've already given several reasons why that's a less than ideal solution.

As per my comment yesterday, if you could answer some of my questions in comment #26, I could put a patch together.

Original comment posted by mpilquist on 2011-03-07 at 04:33 PM

As an appreciative and happy user of google-collections, I'd like to echo the sentiments of ellis.m.a. I haven't yet converted to guava, partially because I cannot get a version of guava built by the committers that's in Maven Central and has an OSGi manifest.

Sonatype recently help the Guice team with the same issues: http://www.sonatype.com/people/2011/01/guice-3-0-rc2-is-in-maven-central/

Original comment posted by carrotsalad on 2011-03-07 at 05:04 PM

We use OSGi in our software development, and while it's certainly not the end of the world when we have to rebuild or patch dependency artifacts to add in the appropriate OSGi metadata to the manifest, it definitely makes my day when I find that it's already there in a library I need.

For small projects whose maintainers are not, themselves, OSGi users, it's often not worth it for them to invest the time in understanding enough about OSGi to create the correct Manifest entries, or to integrate tools like Bnd into their build process. But for larger projects with many and diverse users, I think it's worth it to get the OSGi metadata generated in the authoritative build process, to avoid a situation where there are a ton of third-party out-of-date patched versions floating around in repositories and other places. (I will usually just suck it up and build my own patched version, just to feel confident that my dependencies are what they say they are.)

So, I'd be thrilled if the Guava project were to fold the generation of OSGi metadata into its build process! Thanks.

Original comment posted by ellis.m.a on 2011-03-07 at 09:43 PM

Well, I went ahead and created a patch for the pom.xml that adds OSGI manifest headers to the jar. Patch attached. I hope you'll consider it for inclusion.

To build the jar, I had to skip tests because the test classes don't compile (the com.google.testing.util package has been removed, but the tests still use them). So I ran: mvn package -Dmaven.test.skip

I've checked that the resulting jar loads into Felix too.

Original comment posted by ellis.m.a on 2011-03-07 at 09:47 PM

Correct version attached this time. Apologies.

Original comment posted by konigsberg@google.com on 2011-03-15 at 09:28 AM

Thanks for the information. This will have to wait until the week after EclipseCon, I'm afraid. Sorry for the delay.

Original comment posted by anpieber on 2011-04-18 at 08:37 AM

EclipseCon over for almost a month now and still no update :(

Original comment posted by mikael.barbero on 2011-04-18 at 09:12 AM

Hey guys,

I'm in the process to publish guava-osgi bundles to maven central.

The groupId will be "com.google.guava", the artifact id will be "guava-osgi" and the version tag will be the same as the one used for OSGi (i.e., 9.0.0 for r09, 8.0.0 for r08).

Artifacts should be published by the end of the week, stay tuned!

@ellis.m.a

Also, I'm planning to avoid rebuilding existing bundles each time a release occurs. It will take me some times to change the build script, it should be ok for Guava r10 release.

Original comment posted by mikael.barbero on 2011-04-22 at 01:04 PM

Good news,

guava-osgi files has been deployed to sonatype oss repository https://oss.sonatype.org/content/repositories/releases/

groupId: com.googlecode.guava-osgi
artifactId: guava-osgi

Do not hesitate to provide feedback and/or bug report on the guava-osgi website http://code.google.com/p/guava-osgi/

Original comment posted by anpieber on 2011-04-22 at 01:11 PM

Great news Mikael; Thank you very much!

have you also activated those artifacts to be synced to central?

Original comment posted by mikael.barbero on 2011-04-22 at 01:17 PM

Uhm, dunno how to do :) Do I have to ask for it on the Sonatype JIRA ?

By the way, those maven things are pretty new for me, so I welcome any advice if I'm doing something wrong ;)

Original comment posted by anpieber on 2011-04-22 at 01:49 PM

Hey Mikael, here is the full user guide

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Don't hesitate to ask if you experience any problems; btw the sonatype guys on their MLs are quite friendly and answer very fast on their mailinglist

Original comment posted by js.cedarsoft on 2011-06-27 at 02:42 PM

Hey guys. What about adding the MANIFEST.MF to guava itself?

http://code.google.com/p/guava-osgi/ is not a solution, since it isn't synchronized to central.
So please just add the MANIFEST to the jar. And a lot of the devs out there will be happy...

Original comment posted by konigsberg@google.com on 2011-06-27 at 02:48 PM

js.cedar, thanks for your comment. I don't know what "synchronized to central" means.

Original comment posted by neveue on 2011-06-27 at 04:56 PM

I think he refers to the central Maven repository. The guava-osgi bundle is not available on the central repository, unlike Guava: http://repo2.maven.org/maven2/com/google/guava/guava/r09/

Original comment posted by eric.jain on 2011-10-04 at 01:26 AM

But sooner or later updates get less frequent or stop altogether [...]

It's been almost a week since r10 was released, and guava-osgi hasn't been updated yet. I assume we're still at the "less frequent" stage and haven't progressed to "stop altogether" yet, but perhaps you can see now why some people would consider it an advantage if the official distribution of Guava had an OSGi manifest.

Original comment posted by mikael.barbero on 2011-10-05 at 11:34 AM

guava-osgi has been updated and now provides r10

It has been deployed to maven sonatype oss repository. It is on its way to central sync.

I'm planning to provide patch to the guava team to integrate osgi metadata to the main released jar making it real plain osgi bundles. It is also planned to create a new git repository that will host the p2 repository as provided today by the guava-osgi on svn.

I hope to provide a first patch by the end of this week

Original comment posted by eric.jain on 2011-10-26 at 05:50 PM

Thanks for the guava-osgi update for r10! Guava 10.0.1 was released (a bit over two weeks ago), so I'm looking forward to the next guava-osgi update...

Original comment posted by cpovirk@google.com on 2012-03-12 at 04:04 PM

Martin Ellis has pointed out that (a) the status on this bug is wrong and (b) we haven't given an update. We seem to have wound up with two separate bug entires for this, and worse, we've been updating on the later bug. Since that one has the newest information, I'll mark this one as a duplicate. Sorry for the trouble.

Here's the short progress summary:

"Patch has been applied to master branch."

"I've been trying to push this patch into 11.0.2, but have failed. The problem is that it is doing some work during the wrong phase or goal, and thus changing the contents of guava-11.0.2.jar after the signature has already been generated."

There's more at the linked bug.

Status: Duplicate
Merged Into: #688