On 6 Jun 2012, at 16:51, Christian Edward Gruber wrote: > Hey all, > > So… this sucks rocks, but sadly, the OSGI metadata included in 3.0 is > broken - not in a way that inhibits guice core, but for using any of the > extensions in an OSGI environment.
This statement is not quite correct - the Eclipse-ExtensibleAPI is not an OSGi header, it is only used by Eclipse/PDE tooling (not runtime) and therefore the metadata is not broken for general OSGi users. >From the Eclipse docs at >http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html "The Eclipse-ExtensibleAPI is used to specify whether a host bundle allows fragment bundles to add additional API to the host. This header should be used if a host bundle wants to allow fragments to add additional packages to the API of the host. If this header is not specified then a default value of 'false' is used. Note that this header is only used by tooling (PDE) to construct proper class paths for building. The runtime does not use this header at all. At runtime a fragment is always allowed to add additional packages, classes and resources to the API of the host." So anyone deploying Guice or its extensions at runtime in OSGi should be fine - this particular issue is limited to when you're developing inside Eclipse/PDE and have the extension imported as a project. > The bottom line is this - > http://code.google.com/p/google-guice/issues/detail?id=494. The missing > Eclipse-ExtensibleAPI: true property from the OSGI metadata means that anyone > using guice's extensions in a variety of osgi contexts is broken unless they > repackage guice and the extension into their own osgi bundle. In order to > make my own such project work, I need to build a local version of guice > including that fix (or depend on other people's repackaging of guice). > > I propose a 3.0.1 bug-fix release that simply updates the metadata. > Basically a branch from 3.0 as-released with mcculls' patch pulled in. I wish > I could just update the metadata on maven central repo, but released > artifacts are, as we all probably know, write-once. > > So… any objections to rolling 3.0.1 as-described. And if not… are there > any critical bug-fixes that have made their way in that are worth cherry > picking? This is not a release from head, so I'd rather keep it to a > minimum, but just in case people have urgent things they feel are worth the > trouble. No objections - alternatively has trunk reached a stable enough state for a 3.1 release? There's plenty of good stuff since the last release, such as the new ProvisionListener API. > cheers, > Christian. > > ---- > Christian Edward Gruber - Senior Software Engineer - Java Core Libraries - > Guice > Google :::: +1 (646) 807-9839 [US] :::: +1 (647) 737-9839 [CA] :::: > cgru...@google.com > > > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice-dev" group. > To post to this group, send email to google-guice-dev@googlegroups.com. > To unsubscribe from this group, send email to > google-guice-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-guice-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
