On Jun 6, 2012, at 12:08 PM, Stuart McCulloch wrote: > 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.
Fair comment, though it seems to also affect Tycho, so perhaps it's more fair to say it's a build-time (IDE or otherwise) issue. Tycho seems to honor the setting. >> 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. I haven't been tracking the progress long enough to get a good feel for that. I'm ok with either, if the HEAD is sane enough. Sam? Jesse? Anyone else? The only reason I'd recommend doing a quick 3.0.1 and THEN looking at a 3.1 is that this is quite trivial to whip up and release without (much) fanfare, where I'd rather take a bit of time to roll release notes more thoroughly, and make sure I'm acquainted with what goes out the door, and I'm kind of full up for a bit trying to close down other projects so I can focus on Guice full-time. Christian. -- 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.
