Provide OSGI Bundle #688
Comments
|
Original comment posted by mikael.barbero on 2011-08-14 at 07:28 AM http://code.google.com/p/guava-osgi/ provides OSGI re-packaging of the Guava JAR archives. |
|
Original comment posted by kevinb@google.com on 2011-08-16 at 03:46 PM Should we import that project into a trunk/osgi directory in Guava itself? Users seem repeatedly confused about this. Labels: |
|
Original comment posted by mikael.barbero on 2011-08-16 at 07:44 PM 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 posted by webmas...@fernandoribeiro.eti.br on 2011-08-17 at 04:29 AM I'd support merging the projects very much. |
|
Original comment posted by kevinb9n on 2011-09-01 at 05:30 PM We think this is the right thing to do. Status: |
|
Original comment posted by kevinb@google.com on 2011-10-05 at 05:02 AM (No comment entered for this change.) Labels: |
|
Original comment posted by fry@google.com on 2011-11-16 at 07:40 PM (No comment entered for this change.) Labels: - |
|
Original comment posted by holger.staudacher on 2011-12-23 at 08:56 PM 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 posted by mikael.barbero on 2012-01-01 at 12:08 PM 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 posted by webmas...@fernandoribeiro.eti.br on 2012-01-02 at 02:13 PM 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 posted by webmas...@fernandoribeiro.eti.br on 2012-01-02 at 02:15 PM Holger, I definitely agree with having version numbers in the OSGi bundles, thanks for bringing that up. |
|
Original comment posted by mikael.barbero on 2012-01-02 at 02:38 PM 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 posted by webmas...@fernandoribeiro.eti.br on 2012-01-02 at 02:51 PM 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 posted by mikael.barbero on 2012-01-02 at 02:58 PM 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 posted by webmas...@fernandoribeiro.eti.br on 2012-01-02 at 03:02 PM Sorry, very familiar with GitHub but not Google Code, hope Google takes your contribution and closes this issue soon. |
|
Original comment posted by mikael.barbero on 2012-02-17 at 07:39 AM Patch has been applied to master branch. See https://github.com/google/guava/blob/master/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 posted by fry@google.com on 2012-02-21 at 07:22 PM 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 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. Owner: fry@google.com |
|
Original comment posted by fry@google.com on 2012-02-21 at 07:33 PM 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 posted by mikael.barbero on 2012-02-24 at 10:30 AM 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 posted by cpovirk@google.com on 2012-03-12 at 04:04 PM Issue #64 has been merged into this issue. CC: mikael.barbero |
|
Original comment posted by cpovirk@google.com on 2012-03-12 at 08:45 PM OK, I'm trying to get a handle on all this. First, here are the patches of each type that we have: MANIFEST.MF Maven 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 CC: fry@google.com |
|
Original comment posted by fry@google.com on 2012-03-12 at 09:07 PM You can't reproduce because the change was rolled back in the release branch. Try from master. |
|
Original comment posted by cpovirk@google.com on 2012-03-14 at 06:00 PM 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=-5945646942848050567&name=guava-osgi.diff&token=gh6jFa6J4_LV7DrRWvpGx__BrJo%3A1331583073437 provide any help? Owner: cgruber@google.com |
|
Original comment posted by cgruber@google.com on 2012-03-14 at 08:34 PM will do. c. |
|
Original comment posted by mcculls on 2012-03-14 at 08:56 PM 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 posted by mikael.barbero on 2012-03-14 at 09:05 PM 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 posted by fry@google.com on 2012-03-14 at 09:08 PM 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 posted by mcculls on 2012-03-14 at 09:32 PM 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 posted by mcculls on 2012-03-14 at 10:19 PM 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 posted by cgruber@google.com on 2012-03-20 at 09:39 PM 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 posted by cgruber@google.com on 2012-03-20 at 09:41 PM (sorry - and bake in the signing into a pre-deploy phase) |
|
Original comment posted by cpovirk@google.com on 2012-03-22 at 08:53 PM 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 posted by cgruber@google.com on 2012-03-30 at 03:51 PM I'm prioritizing this as of now. |
|
Original comment posted by kevinb@google.com on 2012-03-30 at 05:59 PM (No comment entered for this change.) Labels: |
|
Original comment posted by cpovirk@google.com on 2012-04-16 at 12:04 PM This will be in 12.0-rc2: 2169c86 Status: |
|
Original comment posted by cpovirk@google.com on 2012-04-16 at 12:10 PM (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 posted by mikael.barbero on 2012-04-16 at 12:14 PM everything seems ok to me. Waiting for 12.0-rc2 to test generated metadata... |
|
Original comment posted by robert.munteanu on 2012-05-01 at 01:59 PM 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 issue created by webmas...@fernandoribeiro.eti.br on 2011-08-14 at 12:31 AM
The project should provide a OSGI bundle in addition to the current JAR archive.
The text was updated successfully, but these errors were encountered: