Provide OSGI Bundle

[GoogleCodeExporter]

The project should provide a OSGI bundle in addition to the current JAR archive.

Original issue reported on code.google.com by webmas...@fernandoribeiro.eti.br on 14 Aug 2011 at 12:31

[GoogleCodeExporter]

http://code.google.com/p/guava-osgi/ provides OSGI re-packaging of the Guava 
JAR archives.

Original comment by mikael.b...@gmail.com on 14 Aug 2011 at 7:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Should we import that project into a trunk/osgi directory in Guava itself?  
Users seem repeatedly confused about this.

Original comment by kevinb@google.com on 16 Aug 2011 at 3:46

• Added labels: Type-Task

[GoogleCodeExporter]

That would be fine, but it could be even better if it integrates trunk ;)

OSGi bundles are just plain old jars with some extra entries in their 
MANIFEST.MF. It is that little invasive !

Everything else provided by guava-osgi is eclipse equinox (the OSGi runtime of 
eclipse) dependant and can stay in its very own project. Moreover, I've heard 
that Eclipse will use Guava very soon, then all eclipse dependant artifacts may 
even move to eclipse.org.

Original comment by mikael.b...@gmail.com on 16 Aug 2011 at 7:44

[GoogleCodeExporter]

I'd support merging the projects very much.

Original comment by webmas...@fernandoribeiro.eti.br on 17 Aug 2011 at 4:29

[GoogleCodeExporter]

We think this is the right thing to do.

Original comment by kevin...@gmail.com on 1 Sep 2011 at 5:30

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by kevinb@google.com on 5 Oct 2011 at 5:02

• Added labels: Milestone-Release11

[GoogleCodeExporter]

Original comment by fry@google.com on 16 Nov 2011 at 7:40

• Removed labels: Milestone-Release11

[GoogleCodeExporter]

Just as a side note, when introducing some OSGi Manifest headers it would be 
good when the exported packages get a version, too.  This enables the usage of 
different versions of guava within the same OSGi container (sometimes needed).

I bundled Guava myself. So, I attached the Manifest. Maybe this helps as a 
starting point.

Cheers Holger

Original comment by holger.s...@gmail.com on 23 Dec 2011 at 8:56

Attachments:

• MANIFEST.MF

[GoogleCodeExporter]

I cloned guava-libraries and modified POM's files to add OSGi metadata so that 
future releases will be native OSGi  bundles.

http://code.google.com/r/mikaelbarbero-ogsi-guava/

Please note that the version in the POM can't be "latest" as it is not a valid 
OSGi version number.

Regards, 

Original comment by mikael.b...@gmail.com on 1 Jan 2012 at 12:08

[GoogleCodeExporter]

Mikael,

We have long had a side project providing OSGi bundles 
(http://code.google.com/p/guava-osgi/), the point is getting the main project 
to provide them instead.

Original comment by webmas...@fernandoribeiro.eti.br on 2 Jan 2012 at 2:13

[GoogleCodeExporter]

Holger,

I definitely agree with having version numbers in the OSGi bundles, thanks for 
bringing that up.

Original comment by webmas...@fernandoribeiro.eti.br on 2 Jan 2012 at 2:15

[GoogleCodeExporter]

Hi,

Actually, I'm one of the guy behind the guava-osgi project :p

The goal of my pull request (i.e. modify the pom file) is to make standard 
Guava releases native OSGi bundles.

If it is accepted, I still want to maintain guava-osgi for its Eclipse p2 
repository.

Regarding the Holger request, it should be noted that guava-osgi already 
provides package versioning and my patch is supporting it too.

Regards, 

Original comment by mikael.b...@gmail.com on 2 Jan 2012 at 2:38

[GoogleCodeExporter]

Hi,

I didn't know that, sorry, anyway this issue is for merging the two projects, 
as I see very little reason to keep them apart.

Original comment by webmas...@fernandoribeiro.eti.br on 2 Jan 2012 at 2:51

[GoogleCodeExporter]

I think I've been unclear. I did a clone of guava code repository to try some 
changes and now I'm doing a kind of "pull request" (if you're not familiar with 
distributed SCM, I advise you to read 
http://help.github.com/send-pull-requests/). I don't want to keep the 
http://code.google.com/r/mikaelbarbero-ogsi-guava/ after the merge.

guava-osgi will only be kept for its p2 repository.

I hope it's clearer.

Original comment by mikael.b...@gmail.com on 2 Jan 2012 at 2:58

[GoogleCodeExporter]

Sorry, very familiar with GitHub but not Google Code, hope Google takes your 
contribution and closes this issue soon.

Original comment by webmas...@fernandoribeiro.eti.br on 2 Jan 2012 at 3:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Patch has been applied to master branch. 

See http://code.google.com/p/guava-libraries/source/browse/guava/pom.xml

11.0.2 and 12.0.0 should be OSGi compliant as-is.

I plan to maintain http://code.google.com/p/guava-osgi/ for past releases and 
to maintain p2 repository (eclipse) with new ones. But guava-osgi maven 
repository (http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22guava-osgi%22) 
will not updated with new releases.

Original comment by mikael.b...@gmail.com on 17 Feb 2012 at 7:39

[GoogleCodeExporter]

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.

At this point I'm going to have to back this change out, unless you can help 
improve the patch such that it only runs at the appropriate time.

It should be easy for you to duplicate the problem I'm seeing by running:

   mvn clean package source:jar site:jar javadoc:jar gpg:sign deploy -Dgpg.keyname=****

Then check that the produced signature is valid:

cd guava/target
gpg --output guava-11.0.2.jar --verify guava-11.0.2.jar.asc

If you can't get to this for 11.0.2, then hopefully we can at least get it 
sorted out by 12.0.0.

Original comment by fry@google.com on 21 Feb 2012 at 7:22

[GoogleCodeExporter]

By the way, this failure is very similar to one I saw in Caliper. I fixed that 
with:

   http://code.google.com/p/caliper/source/detail?r=bb0a375f570488c48173ff1e7718718ca2485edc

I'm not sure exactly what is required in this case, but I presume something 
similar. Given your familiarity with the rules you added, might you be willing 
to attempt the fix?

Original comment by fry@google.com on 21 Feb 2012 at 7:33

[GoogleCodeExporter]

Sorry, i missed the window for 11.0.2

I'll try to fix that tomorrow to have OSGi bits for 12.0.0

Original comment by mikael.b...@gmail.com on 24 Feb 2012 at 10:30

[GoogleCodeExporter]

Issue 64 has been merged into this issue.

Original comment by cpov...@google.com on 12 Mar 2012 at 4:04

[GoogleCodeExporter]

OK, I'm trying to get a handle on all this.

First, here are the patches of each type that we have:

MANIFEST.MF
http://code.google.com/p/guava-libraries/issues/attachmentText?id=64&aid=3167599
416579554830&name=MANIFEST.MF&token=2EHDKwFyzRbqOucGVDrlclHvzJE%3A1331583073428
http://code.google.com/p/guava-libraries/issues/attachmentText?id=64&aid=-440657
9289333798650&name=MANIFEST.MF&token=ni4oBRdjxaY8xgJBPKgBizjsQhM%3A1331583073429
http://code.google.com/p/guava-libraries/issues/attachmentText?id=688&aid=688000
9000&name=MANIFEST.MF&token=zcwF_AMJ6xit-c7zZXKS5RqIOLI%3A1331583561403

Ant
http://code.google.com/p/guava-libraries/issues/attachmentText?id=64&aid=-661166
0255783003259&name=google-collections-issue-64-bnd.txt&token=PcmFOkafLhrx6C-8TI1
dNE9tYhI%3A1331583073429

Maven
http://code.google.com/p/guava-libraries/source/detail?r=53abadc9336bfc8c73ec993
f0c396eff701c853d
http://code.google.com/p/guava-libraries/issues/attachmentText?id=64&aid=-594564
6942848050567&name=guava-osgi.diff&token=gh6jFa6J4_LV7DrRWvpGx__BrJo%3A133158307
3437

We applied and then reverted the first Maven patch because of problems with it. 
 My plan was to reproduce that error and then see whether it exists with the 
second patch.  However, I can't reproduce the error.  Charles, can you help me 
out?

$ git checkout release

# Sync just before osgi support was removed:
$ git reset --hard v11.0.2

# The command you have but without "deploy."
# If I pass deploy, too, I get the 401 error uploading.
$ mvn clean package source:jar site:jar javadoc:jar gpg:sign

$ cd guava/target

$ gpg --output guava-11.0.2.jar --verify guava-11.0.2.jar.asc
gpg: Signature made Mon 12 Mar 2012 04:37:24 PM EDT using RSA key ID 11E9D1AE
gpg: Good signature from "Christopher Povirk <cpovirk@google.com>"

Original comment by cpov...@google.com on 12 Mar 2012 at 8:45

[GoogleCodeExporter]

You can't reproduce because the change was rolled back in the release branch. 
Try from master.

Original comment by fry@google.com on 12 Mar 2012 at 9:07

[GoogleCodeExporter]

Sorry, Charles, I completely missed your response.

Charles and I talked, and we verified that my reset to v11.0.2 did the right 
thing (only because v11.0.2 was in the wrong place (now fixed)).  However, it 
looks like "deploy" is essential to reproducing the problem.  (Note that it 
doesn't deploy "to" Maven Central, only to a staging area, so it's safe for us 
to test with.)  However, we've had deployment troubles for a few months, and 
the Sonatype people haven't figured them out yet, so most of us can't deploy 
and thus can't test this :\

Christian, Charles thought that you might know what needs to be done here.  He 
suspects that we may need to restrict the phase/goal/something during which the 
OSGi setup occurs (org.apache.felix in guava/pom.xml).  Can you try Charles's 
steps on the master branch (including "deploy") and see whether the gpg 
--verify fails as expected?  Or even if not, is it obvious to you what's wrong 
with the current setup?  Does the other patch at 
http://code.google.com/p/guava-libraries/issues/attachmentText?id=64&aid=-594564
6942848050567&name=guava-osgi.diff&token=gh6jFa6J4_LV7DrRWvpGx__BrJo%3A133158307
3437 provide any help?

Original comment by cpov...@google.com on 14 Mar 2012 at 6:00

[GoogleCodeExporter]

will do.

c.

Original comment by cgruber@google.com on 14 Mar 2012 at 8:34

[GoogleCodeExporter]

Whichever patch you go with, I'd recommend using the latest version of the 
maven-bundle-plugin (2.3.7) as it fixes some potential problems that could 
occur when you (re)generate a manifest without cleaning the project first - if 
you're only seeing issues when deploying/releasing then upgrading to 2.3.7 
could fix this.

Original comment by mccu...@gmail.com on 14 Mar 2012 at 8:56

[GoogleCodeExporter]

Sorry for the late answer. 

I did not manage to reproduce the bug (but I forgot to report it).

Hope some Maven gurus may help (or someone from the Apache Felix project).

Original comment by mikael.b...@gmail.com on 14 Mar 2012 at 9:05

[GoogleCodeExporter]

The bug seems to come from the "deploy" phase. Without that it works right. So 
somehow the work which is happening for OSGi needs to be kept out of deploy.

Original comment by fry@google.com on 14 Mar 2012 at 9:08

[GoogleCodeExporter]

You shouldn't need to exclude it during deploy. FWIW the configuration in 
https://github.com/sonatype/sisu-guava/blob/master/guava/pom.xml has been 
successfully used for releasing+deploying. I'd try upgrading to version 2.3.7 
of the plugin first.

Original comment by mccu...@gmail.com on 14 Mar 2012 at 9:32

[GoogleCodeExporter]

FYI, looking at your deploy command:

   mvn clean package source:jar site:jar javadoc:jar gpg:sign deploy -Dgpg.keyname=****

I think this is part of the problem - if you ask Maven to do "mvn ... package 
... deploy" then instead of going through the build lifecycle once it will 
actually run all the executions in the lifecycle up to package, and then 
restart the lifecycle and run through all the executions again up to deploy.

My guess is this isn't noticed with the current setup because javac and jar 
will create binary-identical content. But depending which OSGi patch you're 
using it may add a 'Bnd-LastModified' header to the manifest, which will of 
course change each time it runs. Removing this header with the <_removeheaders> 
instruction should help produce identical content and workaround the issue.

But IMHO the preferred solution would be to add a Maven profile to add the 
source/javadoc/signing steps to the project. Your deploy command would then 
become much simple:

   mvn clean deploy -Dgpg.keyname=**** -Prelease

you'd also avoid restarting the lifecycle, causing the repeated compile+jar 
executions. An example of a release profile can be found in 
https://github.com/sonatype/oss-parents/blob/master/forge-parent/pom.xml#L237

Original comment by mccu...@gmail.com on 14 Mar 2012 at 10:19

[GoogleCodeExporter]

Yeah - i will bake in the source:jar, site:jar, and javadoc:jar into the pom so 
a mvn deploy will pick all those up in the packaging phase.   I'll also take a 
peek at sisu's config and see what we can poach reliably. I've been out of this 
loop for a while, due to other obligations and priorities, but I want to get 
this cleaned up so it's easier to release. 

Original comment by cgruber@google.com on 20 Mar 2012 at 9:39

[GoogleCodeExporter]

(sorry - and bake in the signing into a pre-deploy phase)

Original comment by cgruber@google.com on 20 Mar 2012 at 9:41

[GoogleCodeExporter]

The Sonatype people finally have things fixed up, so we can test things out 
now.  I can reproduce the problem Charles was seeing before.  I've also 
attempted to update the other Maven patch (attached -- I hope it's more or less 
correct), with which I get the same verification failure.

Christian seems to have a plan in mind, so I'll leave this to him.

Original comment by cpov...@google.com on 22 Mar 2012 at 8:53

Attachments:

• issue.64.comment.33.guava-osgi.updated.diff

[GoogleCodeExporter]

I'm prioritizing this as of now.

Original comment by cgruber@google.com on 30 Mar 2012 at 3:51

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 Mar 2012 at 5:59

• Added labels: Milestone-Release12

[GoogleCodeExporter]

This will be in 12.0-rc2: 
http://code.google.com/p/guava-libraries/source/detail?r=2169c86ef5ddd350b1a48ae
d7f917d6c555a7602

Original comment by cpov...@google.com on 16 Apr 2012 at 12:04

• Changed state: Fixed

[GoogleCodeExporter]

(There remains more to do to better support OSGi, but I think our 12.0-rc2 
changes cover the specific request of this bug...?)

Original comment by cpov...@google.com on 16 Apr 2012 at 12:10

[GoogleCodeExporter]

everything seems ok to me. Waiting for 12.0-rc2 to test generated metadata...

Original comment by mikael.b...@gmail.com on 16 Apr 2012 at 12:14

[GoogleCodeExporter]

I've deployed the 12.0 Guava bundle in a Sling application ( using Apache Felix 
) and using the collections part of Guava works just fine.

Thanks for your efforts!

Original comment by robert.munteanu on 1 May 2012 at 1:59

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit